in principle, I like to work with both, JDO and JPA. but using either
of them requires (in most cases) use of the osiv pattern, which in
turn results in using something like spring. Keeping the discussions
about request and startup performance in mind, apps on GAE shouldn't
make use of too many
On Wed, Jan 27, 2010 at 2:44 AM, datanucleus andy_jeffer...@yahoo.com wrote:
Exposing Key to a user is not (in my opinion) a requirement for
*providing* a JDO impl on GAE/J. Other datastores have their own
internal id and we don't expose theirs (e.g db4o).
...
And, of course, all of that
Going back to the original poster's request, would you like to provide
JDO (on GAE/J) equivalents of the annotated entities that described in
BAD IDEA #1, BAD IDEA #2, and GOOD IDEA? That is:
I only represent JDO, as a spec, not how GAE/J have implemented it.
The docs for that are provided in
On Wed, Jan 27, 2010 at 3:28 PM, datanucleus andy_jeffer...@yahoo.com wrote:
I only represent JDO, as a spec, not how GAE/J have implemented it.
The docs for that are provided in the JDO spec and on the DataNucleus
website. I fail to see anything controversial in how they are
represented in
Jeff,
I simply reply to your rant about JDO annotations. Nowhere do I say
JDO is the solution for all tasks. My goal is not as you state either,
but instead to provide persistence via *any* standardised API to all
available datastores, and to correct misconceptions about those APIs
(whether JDO
sorry for this maybe thumb question, but I just want to make sure:
both frameworks are making the needs for open session in view (as
almost required when using jdo/jpa in web applications) obsolete,
or?
regards,
andr
On 26 Jan., 12:18, John Patterson jdpatter...@gmail.com wrote:
Hi Chau, yes
On Tue, Jan 26, 2010 at 5:50 AM, a.maza andr.m...@gmail.com wrote:
sorry for this maybe thumb question, but I just want to make sure:
both frameworks are making the needs for open session in view (as
almost required when using jdo/jpa in web applications) obsolete,
or?
Neither Twig nor