-> Nacho
SimpleDS looks great,but why have you decided to tie it to Spring?
~Morten
On 3 Nov., 20:01, Vince Bonfanti wrote:
> 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 entiti
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 m
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 wrote:
>
> P.S. Because of issue 2097
> (http://code.google.com/p/googleappengine/issues/detail?id=2097), the
>
P.S. Because of issue 2097
(http://code.google.com/p/googleappengine/issues/detail?id=2097), the
write-behind task doesn't work on the development server, so it always
defaults to write-through (which is a nice test of the watchdog
mechanism). The write-behind task works fine on the production
ser
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 a
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 wrote:
> Hi all,
>
> We have been developing a p
>
> I will try to do so during 1-2 weeks and give you some input. I hope
> that you plan to keep your project alive.
>
We are using it on a daily basis :)
I have the intention to make small additions for the typical AppEngine daily
stuff (sharding and multiple index), but we still have to give it
Thanks for javadoc.
Several months ago I ported my application to Google App Engine and
reported my adventures here:
http://hoteljavaopensource.blogspot.com/2009/09/migration-to-google-app-engine.html
Finally I realized that I reduced my JPA layer to basic CRUD
operations and simple query. To kee
> i.e DataNucleus and JDO *does* support that, and the google-provided
> plugin doesn't.
>
I didn't pretend to mean that it was a limitation in datanucleus, but
specifically for the GAE plugin. Thanks for pointing out the difference.
>
> FWIW 1. a more accepted way of referring to such relations
> If instead you're talking about GAE/J specifics, as per the link that
> you provided, then that is a different issue ... dependent on Googles
> plugin for DataNucleus. Only they can comment on that.
or as per the doc you linked to
"The App Engine implementation of JDO does not yet implement thi
> 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 mu
Sorry, I should have been more explicit. Just for the record, we are talking
about this:
http://code.google.com/appengine/docs/java/datastore/relationships.html#Unowned_Relationships
With JPA+RDBMS a relationship between two objects (say, "Invoice" and
"Customer") could be implemented by a "custo
> Now that we are discussing it, I am curious: why does datanucleus only
> support owned relationships? There is not that much difference between the
> typical Foreign Key field and a GAE Key property.
JDO and JPA support **object** relationships, being Java standards for
O-O persistence.
Having
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 publising
On Fri, Oct 23, 2009 at 6:06 PM, datanucleus wrote:
>
> > * 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, w
> * 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 w
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.
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 ra
> 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
co
> 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 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
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
> 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
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 not
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 b
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
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
Awesome!
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. The detach/attach is also problematic when
dealing with caching and transaction. I also noticed small JDO objects
are much bigger than i
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,
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 wrote:
> Hi all,
>
> We have been developing a persistence framework for the AppEngine
> Datastore based on the raw DatastoreService
30 matches
Mail list logo