Thank you very much for your feedback Marton :)
I hope you don't mind, but i will write some further comments to sustain my
cause.
I also would like to hear the opinion of someone from Google. I know you
guys recommend JDO, but can you give me some arguments against using the low
level API, besides portability (i plan to stick to google datastore
services) or code complexity. Why not harness the full power and flexibility
that the datastore has to offer ?!
On Mon, Sep 21, 2009 at 6:35 PM, Marton Papp mapr...@gmail.com wrote:
Hi Corneliu!
I also had doubts about using JDO in GAE when I started to work with
it. Especially because I met several bugs and it was annoying and time
wasting to figure out what was going wrong. But then the bugs were
fixed in the next release, so I think the guys are generally doing a
good job.
About the limitation with the non-existing property, you are right. It
seems to me that JDO will create a property with a null value once you
declare and map it. Do you have a real-life scenario where this
limitation is an issue that you cannot overcome with the features
provided by JDO? I think if you really need to have some entities
having some properties, and others not, and still use JDO, then you
could try to *map different classes to the same database entity*, with
different properties defined in the classes. I have never tried that
though, so I am not sure if it would work, and definitely would not be
convenient.
How would i map different classes to the same database entity? They need to
have the same name. What do i do? I put them in different packages? On the
other hand, if i have an older version and a newer version of the same
object (with an extra field let's say) and i want to update a common field
on all objects (both old and new), i can do it with a couple of lines of
code using the low level API.
Again i would like the opinion of someone from Google. Why hide this
wonderful feature (dynamic schema - different properties of objects of the
same kind) while using JDO.
About mapping collections with many entities inside, I think I just
wouldn't do it. If the collection is too big to be effectively loaded
into memory, then you are right to be using queries instead. In this
case you should not map it as a collection, but handle the parent-
child relationship explicitly. But still, collection mapping can be a
convenient option if you have only a small number of entities in your
collection. This does not make JDO less flexible, on the contrary, it
introduces an extra service.
Your idea about processing just part of the results at once in a query
seems to be okay. I think a similar approach is described to handle
pagination of large result sets somewhere in the forums.
As for me, I would not recommend you to create your own data access
layer using the low level API unless you really need it or you really
do not need any of the features that JDO provides. It still provides
some convenient features that you would have to live without or
reimplement if you decide not to use JDO (starting with mapping java
classes to persistent storage, which I think is a good thing). Most of
the problems you mentioned are not solved by using the low level API
anyway, so if you want to create some classes that make data access
easier for you applications then you can build them on top of JDO as
well, without any major drawbacks.
And as final reason why to use JDO, these guys who wrote the docs
recommended to do so, and they must have some reason to say that. :)
Marton
--
Corneliu Paul Lupulet
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google App Engine for Java group.
To post to this group, send email to google-appengine-java@googlegroups.com
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en
-~--~~~~--~~--~--~---
