[jira] [Created] (JDO-754) Add more logical complement operator JDOQL query tests
Michael Bouschen created JDO-754: Summary: Add more logical complement operator JDOQL query tests Key: JDO-754 URL: https://issues.apache.org/jira/browse/JDO-754 Project: JDO Issue Type: Task Components: tck Affects Versions: JDO 3.1 Reporter: Michael Bouschen Assignee: Michael Bouschen Fix For: JDO 3.2 Possible test scenarios: !(field != value) !(field != null) !!(field != value) !!(field != null) !!!(field != value) !!!(field != null) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: A new general method to update object databases / Should it be included in Java Data Objects, JDO ?
Hi everybody, -- Sorry the delay in my answer First, I made slides (a PDF) about the embed method and how its algorithm works: https://drive.google.com/file/d/0B8eKvcE21R9RMkNPYlZiOTEwZnM/view I don't know if the Smalltalk community or other communities have this kind of method (embed) but I believe not, because otherwise we would probably know it! It is true that gc is not a new concept in db world but but perhaps before it has been used quite separately in the db. What is new in the embed method? I think that at least the high level method/abstraction where the result of the embed operation is defined clearly between two memory systems (i.e. “the network level understanding”). Also I think that in the next lower level binding the update part and the gc part together (“embed = update + gc”) is a new idea. And what is important in this binding is that the the update part is able to collect information for the gc part and the gc part has full network/graph level understanding in db even it is done locally and therefore efficiently. Reference cycles (circular substructures) are not problem in the algorithm as is described in the demo implementation. On the other hand, gc can be done more easily when garbage (or db) does not contain circular substructures and both algorithms can be applied in real systems, the simpler first. It is true that storing reference counts takes some extra bytes in nodes in db. That does not sound a big problem, because objects often contain quite much user data and memories are quite big today, even in small devices. Updating of reference counts is not a big performance problem in my opinion. If reference counts must be updated, it often means that you are making a big update operation when updating of reference counts is a small part of the operation. In addition, you can often update reference count with the same SQL update statement (in O/R systems) which updates fields containing user data. (However in a pure reference lose you are not updating the user data of an object.) Also note that it is possible to keep reference count information (sum of increments and decrements) in the run-time memory during the embed method. Therefore, if, for example, a node loses a reference and gets a new reference in an update operation, no updates are needed for the reference count. I demonstrate this in the demo implementation in the level of single (parent) node (the method handleReferencesFromGrayNodesInDB()). Perhaps in practice most update operations do not change references of objects. In these cases the embed method is, of course, a pure store/update operation. Personally I think that the db model where the persistence is a concept in the db, and is defined by reachability from persistent root nodes is natural for programmers and designers, and very object db like. Defining temporally, during a single update operation, the persistence of a node or some nodes does not sound theoretically/practically clear to me. Note also that when persistence is defined by reachability, you can at anytime make a selected node in the db as a persistent root node to be sure that it, and reachable nodes from it, will not disappear in future operations. This simple method is implemented in the demo implementation. It is incrORC(), the opposite is decrORC() (which is a general delete operation). Just as Tilmann says I also think that the embed method has a solid theoretical foundation(!). Therefore, in my opinion, the embed method is not just a one new update method. If I think with the terms of protocols then, in my opinion, the embed method defines a new natural higher level layer between a client program and the db (remote memory). This layer is clean and makes updating a natural and easy operation for a programmer; updating becomes nearly as easy as modifying object structures in the run-time memory. And even though the embed method fits best for complex update operations it is also useful in quite simple situations, for example, when a single reference is replaced with a new one and perhaps some scalar fields of some objects are updated at the same time. There are of course some worst, or tedious, cases for the plain embed method. However it is possible to derive additional “decorated” methods from the plain embed method. Also these methods are still quite general and easy to understand for a user as network level operations. I describe examples of these methods (”handlings”) in Notes paragraph in my blog. http://hvirkkun.blogspot.fi/2016/04/a-new-communication-theory-on-complex.html Gc can be made even more efficient, and it can be helped easily if an application has extra knowledge of non-garbage nodes, as I explain in the demo implementation. And, of course, embed can be called for any substructure, which increases efficiency of the operation. These features tackle many inefficiencies and make the embed more versatile. However, still also simple update commands provided separately can be
[jira] [Commented] (JDO-753) Review Tomcat port configuration
[ https://issues.apache.org/jira/browse/JDO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15315907#comment-15315907 ] Andy Jefferson commented on JDO-753: Hello, care to share with us what relevance this has to v3.0.1 of the JDO API?! I don't see the relevance of Tomcat to an Apache project that simply generates a specification document, and API, and a TCK for that API. Where is Tomcat involved in this? Do you perhaps have the wrong project? > Review Tomcat port configuration > > > Key: JDO-753 > URL: https://issues.apache.org/jira/browse/JDO-753 > Project: JDO > Issue Type: Bug > Components: site and infrastructure >Affects Versions: JDO 3 update 1 (3.0.1) > Environment: Linux-based hosting: > Java Servlets (JSP via Tomcat engine) > Apache ASP > Python > PHP5 > JSON PHP Extension >Reporter: Roger Mbiama > Labels: build > Fix For: JDO 3 update 1 (3.0.1) > > Original Estimate: 504h > Remaining Estimate: 504h > > /* > * new additional configuration > */ > > connectionTimeout="2" > redirectPort="8443/smb" /> > > >unpackWARs="true" > autoDeploy="true" xmlValidation="true" > xmlNamespaceAware="false"> > domain.net > > > > org.apache.tomcat/tomcat-dbcp/9.0.0.M6.location = > /var/www/vhostst/domain.net/httpdocs/repositoryDB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JDO-753) Review Tomcat port configuration
[ https://issues.apache.org/jira/browse/JDO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Mbiama updated JDO-753: - Description: /* * new additional configuration */ domain.net org.apache.tomcat/tomcat-dbcp/9.0.0.M6.location = /var/www/vhostst/domain.net/httpdocs/repositoryDB was: /* * new additional configuration */ domain.net > Review Tomcat port configuration > > > Key: JDO-753 > URL: https://issues.apache.org/jira/browse/JDO-753 > Project: JDO > Issue Type: Bug > Components: site and infrastructure >Affects Versions: JDO 3 update 1 (3.0.1) > Environment: Linux-based hosting: > Java Servlets (JSP via Tomcat engine) > Apache ASP > Python > PHP5 > JSON PHP Extension >Reporter: Roger Mbiama > Labels: build > Fix For: JDO 3 update 1 (3.0.1) > > Original Estimate: 504h > Remaining Estimate: 504h > > /* > * new additional configuration > */ > > connectionTimeout="2" > redirectPort="8443/smb" /> > > >unpackWARs="true" > autoDeploy="true" xmlValidation="true" > xmlNamespaceAware="false"> > domain.net > > > > org.apache.tomcat/tomcat-dbcp/9.0.0.M6.location = > /var/www/vhostst/domain.net/httpdocs/repositoryDB -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JDO-753) Review Tomcat port configuration
[ https://issues.apache.org/jira/browse/JDO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Mbiama updated JDO-753: - Environment: Linux-based hosting: Java Servlets (JSP via Tomcat engine) Apache ASP Python PHP5 JSON PHP Extension was: eNom's Linux-based hosting: Java Servlets (JSP via Tomcat engine) Apache ASP Python PHP5 JSON PHP Extension > Review Tomcat port configuration > > > Key: JDO-753 > URL: https://issues.apache.org/jira/browse/JDO-753 > Project: JDO > Issue Type: Bug > Components: site and infrastructure >Affects Versions: JDO 3 update 1 (3.0.1) > Environment: Linux-based hosting: > Java Servlets (JSP via Tomcat engine) > Apache ASP > Python > PHP5 > JSON PHP Extension >Reporter: Roger Mbiama > Labels: build > Fix For: JDO 3 update 1 (3.0.1) > > Original Estimate: 504h > Remaining Estimate: 504h > > /* > * new additional configuration > */ > > connectionTimeout="2" > redirectPort="8443/smb" /> > > >unpackWARs="true" > autoDeploy="true" xmlValidation="true" > xmlNamespaceAware="false"> > domain.net > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (JDO-753) Review Tomcat port configuration
Roger Mbiama created JDO-753: Summary: Review Tomcat port configuration Key: JDO-753 URL: https://issues.apache.org/jira/browse/JDO-753 Project: JDO Issue Type: Bug Components: site and infrastructure Affects Versions: JDO 3 update 1 (3.0.1) Environment: eNom's Linux-based hosting: Java Servlets (JSP via Tomcat engine) Apache ASP Python PHP5 JSON PHP Extension Reporter: Roger Mbiama Fix For: JDO 3 update 1 (3.0.1) /* * new additional configuration */ domain.net -- This message was sent by Atlassian JIRA (v6.3.4#6332)
