Great! Since someone else is now using this besides me, I've added
more comments. Also, I've added some testcases and fixed an issue when
invoking put() with entities that contain partial keys. If your
entities don't have complete keys when invoking put(), you should go
get the latest code.
Let
One feature I see useful for a layer atop the Low-Level API is
asynchronization. Since you'll never know how much time a Low-Level
API call will take it should automatically create Tasks for them,
writes atleast.
On Oct 22, 10:37 am, Nacho Coloma icol...@gmail.com wrote:
Hi all,
We have been
You might be interested in my CachingDatastoreService class:
http://code.google.com/p/gaevfs/source/browse/trunk/src/com/newatlanta/appengine/datastore/CachingDatastoreService.java
It has the following features:
- Implements the com.google.appengine.api.datastore.DatastoreService,
so it's
Hi Vince
Thanks for sharing.
I've modified my persistence framework to incorporate your class and it
works very well.
kind regards
Roy
On Mon, Nov 2, 2009 at 8:15 PM, Vince Bonfanti vbonfa...@gmail.com wrote:
P.S. Because of issue 2097
With JPA+RDBMS a relationship between two objects (say, Invoice and
Customer) could be implemented by a customer attribute inside the
Invoice class. In the RDBMS, this is translated to a CUSTOMER_ID column in
the INVOICE table. Datanucleus does not support this (the relationship must
be
I didn't use Spring, but I found detach/attach annoying and irrelevant
in GAE context because:
1. Without detaching, when you update a field, and later on close the
PM, the object will be committed regardless. This makes no sense in
GAE as 99.99% of time you want to control what you commit or
1. Without detaching, when you update a field, and later on close the
PM, the object will be committed regardless. This makes no sense in
GAE as 99.99% of time you want to control what you commit or not.
Worse yet if you persist other object and have a transaction, it might
fail because the
I think most complains about JDO in this group is not saying that JDO
has issues. It just that GAE is so different then traditional
environments that old frameworks aren't 100% suitable. If there's a
modify version of JDO that strip out irrelevant features, and put in
some important low level api
I think most complains about JDO in this group is not saying that JDO
has issues. It just that GAE is so different then traditional
environments that old frameworks aren't 100% suitable. If there's a
modify version of JDO that strip out irrelevant features, and put in
some important low
There is absolutely nothing in the JDO ***API*** that is irrelevant to
GAE/J and BigTable.
I disagree, and that's the main reason why we developed our own
framework. These are just some random thoughts about this subject:
* Transactions in JDO is a global thing tied to the persistence store
I recently played with the lower level API as well. Some of the
features are not available in JDO, like reserving a key before
committing a new object.
Yes, we wanted to get access to those. Specially, the create several
keys at once and persist several entities at once are great, we
combined
Do you have some more doc/java doc ? I was browsing through your page
and found nothing. As far as I caught you implemented simple set of
CRUD operations on items and simple query mechanism. Am I right ? The
decision to get rid of relationships is very sound because this GAE/J
implementation is
I have uploaded the generated javadoc here:
http://code.google.com/p/simpleds/downloads/list
I haven't had time to review it yet, so take it with a grain of salt. The
list of features you should look for are:
* CRUD operations at the EntityManager interface
* SimpleQuery
* PagedQuery
That's it.
* Transactions in JDO is a global thing tied to the persistence store
(one database = one transaction), but for GAE it's one transaction per
entity group. It's perfectly reasonable to execute two transactions at
the same time, which is hard to fit into the traditional development
model with
On Fri, Oct 23, 2009 at 6:06 PM, datanucleus andy_jeffer...@yahoo.comwrote:
* Transactions in JDO is a global thing tied to the persistence store
(one database = one transaction), but for GAE it's one transaction per
entity group. It's perfectly reasonable to execute two transactions at
I believe there are a lot of reasons and use cases not to go the JDO/
JPA way and look for a light weight solution. I came up with a similar
idea like Nacho and created a simple class to persist Java objects
using the low-level API. However I consider my code not being in a
state yet for
Sounds good. I also think I'll focus much of my attention on the low-
level API, so this could be very useful!
Regards,
Richard
On Oct 22, 11:37 am, Nacho Coloma icol...@gmail.com wrote:
Hi all,
We have been developing a persistence framework for the AppEngine
Datastore based on the raw
I did more or less the same thing for the same reasons, and with the same
happy result.The only difference for me was instead of annotations, I
generate my model from an RDBMS. This way I know I can port my app to an
RDBMS world should GAE ever go the same way as Google Notebook.
On Thu, Oct 22,
My goal wasn't to economise on api _ms so I haven't done any comparisons.
afaik, commit is done at an entity level, so I don't monitor individual
fields for changes. If I'm wrong then it wouldn't be too difficult to
build dirty flags into my DTO setters.
My advice to anybody building apps for GAE
The name initially confused me because it made me think of
http://www.opends.org/
Nacho Coloma wrote:
Hi all,
We have been developing a persistence framework for the AppEngine
Datastore based on the raw DatastoreService API. For our (simple)
persistence case, both JDO and JPA were a
Peter, it was gratifying to hear you say detach/attach is also problematic
when dealing with caching and transactions because I've been banging my head
against the wall trying to write integration tests with GAE's datastore, using
JDO and Spring's transactions.
I either get the is managed by
21 matches
Mail list logo
