[jira] [Commented] (JDO-748) Tyops in spec and dead link on homepage
[
https://issues.apache.org/jira/browse/JDO-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14741135#comment-14741135
]
Craig L Russell commented on JDO-748:
-
Here are links that work for me:
https://svn.apache.org/viewvc/db/jdo/
http://svn.apache.org/viewvcs/db/jdo/
svn.apache.org/viewcvs/db/jdo
The infra team at Apache should be able to help here.
> Tyops in spec and dead link on homepage
> ---
>
> Key: JDO-748
> URL: https://issues.apache.org/jira/browse/JDO-748
> Project: JDO
> Issue Type: Improvement
> Components: site and infrastructure, specification
>Reporter: Tilmann Zäschke
>Priority: Trivial
> Labels: documentation, homepage
> Fix For: JDO 3.2
>
>
> Section 12.10 uses a wrong font:
> 1) The last paragraph mentions "PersistenceManager.setMultithreaded"
> and "getMultithreaded". Both should presumably use code-font and possibly
> have trailing '()' added.
> Section 12.11 of the spec contains some typos:
> 3) The 3rd paragraph starts with a '.' which should presumably be at the end
> of paragraph 2.
> 4) The code after paragraph 5 should use a code font
> 5) The code after paragraph 6 should use a code font
> On the home page (https://db.apache.org/jdo/svn.html) in the second section
> ("Web Access to Subversion"):
> 6) The link for browsing SVN (http://svn.apache.org/viewcvs/db/jdo) reports
> "Not Found The requested URL /viewcvs/db/jdo was not found on this
> server."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-735) Make PersistenceManager and Query support AutoCloseable (JDK1.7+)
[ https://issues.apache.org/jira/browse/JDO-735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14741106#comment-14741106 ] Michael Bouschen commented on JDO-735: -- Looks good. Should we keep the test class CloseThrowsExceptionWhenActiveTx.java in svn? I don't think so, so if everyboyd agrees I will remove it. > Make PersistenceManager and Query support AutoCloseable (JDK1.7+) > - > > Key: JDO-735 > URL: https://issues.apache.org/jira/browse/JDO-735 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > Attachments: CloseWithActiveTxRollsBack.java > > > So then it can be used with JDK1.7+ try-with-resources, as per > http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JDO-734) Ability to save a (created) query as a named query for later use
[
https://issues.apache.org/jira/browse/JDO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson resolved JDO-734.
Resolution: Fixed
> Ability to save a (created) query as a named query for later use
>
>
> Key: JDO-734
> URL: https://issues.apache.org/jira/browse/JDO-734
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-734.api.patch, SaveAsNamedQuery.java
>
>
> When a user goes to the trouble of creating a query to retrieve some
> information it is a common enough scenario that this will need to be
> performed again during the application lifetime. Being able to save a query
> (once created) as a named query (in the PMF) would mean that applications can
> skip the generation step off for subsequent runs.
> Suggested API change would be to add a single method to Query.
> Query q = pm1.newQuery("SELECT p FROM Person p WHERE firstName == :param");
> q.saveAsNamedQuery("PeopleWithName");
> q.execute("John");
> ... (some time later)
> Query q = pm2.newNamedQuery(Person.class, "PeopleWithName");
> q.execute("Brian");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14741115#comment-14741115 ] Craig L Russell commented on JDO-652: - Changing the structure of the specification would mean a really lot of work that I'm not sure is worth the effort. I'd suggest adding a section in Chapter 14 that deals with the new query strategy. I'll take a look at making the initial changes. > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > Attachments: typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-734) Ability to save a (created) query as a named query for later use
[
https://issues.apache.org/jira/browse/JDO-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1474#comment-1474
]
Michael Bouschen commented on JDO-734:
--
I don't think there is anything left, so marking it as resolved is fine.
> Ability to save a (created) query as a named query for later use
>
>
> Key: JDO-734
> URL: https://issues.apache.org/jira/browse/JDO-734
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
> Fix For: JDO 3.2
>
> Attachments: JDO-734.api.patch, SaveAsNamedQuery.java
>
>
> When a user goes to the trouble of creating a query to retrieve some
> information it is a common enough scenario that this will need to be
> performed again during the application lifetime. Being able to save a query
> (once created) as a named query (in the PMF) would mean that applications can
> skip the generation step off for subsequent runs.
> Suggested API change would be to add a single method to Query.
> Query q = pm1.newQuery("SELECT p FROM Person p WHERE firstName == :param");
> q.saveAsNamedQuery("PeopleWithName");
> q.execute("John");
> ... (some time later)
> Query q = pm2.newNamedQuery(Person.class, "PeopleWithName");
> q.execute("Brian");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Dynamic objects
Hi Andy, There's been a lot of thinking about this since my last mail and I've come to the conclusion that for my needs it will probably be better to use a standard (possibly in-core) RDBMS and use the various callbacks to update the CAD attributes in the CAD objects, or create or delete them, so I won't need a custom datastore implementation. There is however another gray zone: dynamic behavior. There is one use case where I get a model description (in form of an ECore EMF model) and would like to use the dynamic EObject implementation, which basically stores all object fields in an array and has one getter and one setter, with the field ID as a parameter. A pre-enhanced class could probably do the switching job between the StateManager's view (field numbers) and the EMF view (attribute/reference id's). There is however an issue in the fact that all objects have the same Java class and only have an eClass() method which returns the "real" EMF class, and I suspect datanucleus to rely strongly on this class to decide what to do about an object, fetch metadata, etc, etc. Of course, one could create at runtime new "real" subclasses just to have pc.getClass() return different values (and this still does not solve everything), but I would prefer to have a pluggable mechanism to get class metadata / class name for an object, rather than relying on "getClass()", having an optional class resolver property in the PMF, or something like this. Do you have a feeling about the feasability of this approach (i.e. how many changes should be done to implement it everywhere where needed in the code and could it be integrated in the "mainstream" code) ? Regards, Gordan Andy Jefferson wrote: Hi Gordon, A long time ago (2000 !), I wrote a partial implementation of the JDO 1.0 draft spec to make sure the application uses an object API (and not just raw JDBC); the application still runs, but now uses datanucleus. Now, after a long period of inactivity in the JDO field, I've got to write an exotic datastore plugin where the data objects are stored as CAD drawable (or not) objects residing in a CAD drawing and where the object properties are CAD attributes of the CAD objects. Is there a document giving guidelines about the implementation of a new datastore for datanucleus, or should I better start with something roughly similar (maybe excel) or do you have the feeling it would be better to start from scratch ? Well there is a very basic document http://www.datanucleus.org/documentation/development/new_store_plugin_howto.html but it only really touches the surface on what you'll need to do. I'd definitely start from scratch but copy in features (from the most similar plugin, excel? odf?) as you need them. It comes down to what capabilities your datastore has, in terms of schema generation (some of the plugins provide this), or in-datastore querying (again, some do like Cassandra, MongoDB ... but others such as Excel, ODF don't), etc. Feel free to ask questions if you get stuck Maybe later on in your experiences you can contribute an update to that document based on what you found in doing it Regards
