[appengine-java] JDO bug - won't persist parent class attributes - has it been fixed?
I remember there was a bug denoted somewhere in the documentation * (http://code.google.com/appengine/docs/java/datastore*http://code.google.com/appengine/docs/java/datastore) that JDO won't persist properties/attributes of the parent classes. Has this been fixed in the latest release? -- 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 -~--~~~~--~~--~--~---
[appengine-java] Re: JDO vs low level API
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 -~--~~~~--~~--~--~---
[google-appengine] Re: Index appears as Serving but query return DatastoreNeedIndexException
Hello! Thank you for your answers :) This is the JDO query that gets executed: SELECT FROM biz.ebas.entities.server.DbCustomer WHERE version == arg0 PARAMETERS String arg0 ORDER BY encodedKey ascending RANGE 0,26 And this is the exception i get: javax.servlet.ServletContext log: Exception while dispatching incoming RPC call com.google.gwt.user.server.rpc.UnexpectedException: Service method 'public abstract biz.ebas.entities.shared.EntitiyList biz.ebas.client.EntitiesService.retrieveData(biz.ebas.common.QueryRequest) throws biz.ebas.entities.shared.NotLoggedInException' threw an unexpected exception: com.google.appengine.api.datastore.DatastoreNeedIndexException: no matching index found. at com.google.gwt.user.server.rpc.RPC.encodeResponseForFailure(RPC.java:360) at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:546) On Mon, Sep 7, 2009 at 2:17 PM, Nick Johnson (Google) nick.john...@google.com wrote: Hi Cornel, What are the queries you are trying to execute against the index, and what is the full text of the exception you get? -Nick Johnson On Sun, Sep 6, 2009 at 10:41 PM, Cornel corneliu.lupu...@gmail.com wrote: Hello! My application id is cosinux68. I've uploaded the following index definitions: - kind: DbCustomer properties: - name: version - name: __key__ - kind: DbCustomer properties: - name: version - name: __key__ direction: desc They appear as Serving but my queries return DatastoreNeedIndexException. I'm sure they're the correct indices for the query because they were also autogenerated in hosted mode. If i try to vacuum them, i can't find them in the list! If i try to upload them again nothing changes. So what can i do? -- Nick Johnson, Developer Programs Engineer, App Engine -- Corneliu Paul Lupulet --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[appengine-java] Re: How to make a query using low level API using the 'key' property?
I noticed that i can make a query like this: DatastoreService ds = DatastoreServiceFactory.getDatastoreService(); Query query = new Query(DbContact); query.addFilter(__key__, FilterOperator.GREATER_THAN, KeyFactory.stringToKey(a_key_string)); And it works. It fetches the correct results. Then i also noticed i can do this (locally on my computer; i haven't tested this on app-engine yet): entity.put(__key__, some value); ds.put(entity); Using the datastore viewer i can see the object with this property (__key__) and the corresponding value i've set. Then if try a query like this: q1.addFilter(__key__, FilterOperator.EQUAL, some value); it doesnt' fetch any results! So can someone explain the mechanism of what is happening over here? :) One last thing i've noticed: If i try the following line in DataViewer -- Query (using GQL): SELECT * FROM DbCategory where __key__ 'a' I get: server error(500) Server Error A server error has occurred. And also, are there any other reserved properties like __key__ i should be aware of, or which are useful for special kinds of queries.? On Fri, Sep 4, 2009 at 2:17 PM, Cornel corneliu.lupu...@gmail.com wrote: Hello, How can i make a Query using the lowlevel API, similar to this: select * from Entity where key certain_key ? In JDO i would do something like this: select * from Entity where encodedKey a_key_string where encodedKey is my objects' primary key: @PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) @Extension(vendorName=datanucleus, key=gae.encoded-pk, value=true) private String encodedKey; -- 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 -~--~~~~--~~--~--~---
[google-appengine] Re: Indexes stuck in 'Building' state. Cannot vacuum ('because they no longer exist')
I've tried to 'upload' again those 2 index definitions that were stuck in building. It seems they reached 'serving' now, and i was able to vacuum them. On Thu, Sep 3, 2009 at 12:28 PM, Cornel corneliu.lupu...@gmail.com wrote: Hello! I have two index stuck in 'Building' state, for the past 12 hours. I still have entities in the datastore, but they should have finished building by now. I can't vacuum them with appcfy.py because it says they are no longer there. I see the 'trend' is to ask one of guys to help me out vacuum the indexes (my application id is 'cosinux68'). But why don't you implement a force clear indexes' feature? :) Thank you, Cornel -- Corneliu Paul Lupulet --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---
[google-appengine] Re: Transactions
Hello I don't think my message got on the group: On Thu, Aug 6, 2009 at 10:30 PM, Cornel corneliu.lupu...@gmail.com wrote: Hello. I'm using app engine to write a business application. I've read that during a transaction one can modify only entities within the same entity group. How would one approach the following scenario? : Consider the Account object with the Owner and Credit fields. If i want to make a credit transfer between accounts A and B (A.credit--; B.credit++), it must be done in a single transaction. That can only happen if A and B are in the same entity group (from what i understand) Since a credit transfer can be done between any two random accounts, i must put them all in the same entity group; but this way, two unrelated transfers (A to B and C to D let's say) cannot be done at the same time anymore. Which again is not desired (i understand that having a single big entity group is bad practice) I think this is a pretty general problem (not related only to this scenario), so how is it solved? -- Corneliu Paul Lupulet --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google App Engine group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~--~~~~--~~--~--~---