First of, sorry for the delay in my answer and thank you for trying out the container.
Yes, it sounds very likely that you would get a exception if you try to use the container with entities that does not have a version field as the container expects the field. All items created with the container should have a version field. If you are manually inserting entities you should as you say create a ‘version’ property. I will have a look if the container could be modified so that it would still work without the version field. But for now, include it.
EDIT
This should be fixed in version 0.6.1. Entities in the datastore no longer needs to be equipped with a “version” property. The container does neither add a “version” property if optimistic locking is disabled.
Johan - I just independently released a fairly related GAE-based add-on (see http://vaadin.com/forum/-/message_boards/message/31262) called GAEDatastoreContainers. I was unaware of your project. Henri Sara suggested I contact you and discuss possibly merging the projects. That would mean taking the code in my project and merging it into yours. Yours is the more advanced and has the nicer name. Please take a look and see if this is something you would like to do.
I had a look at your project. I haven’t played around with JDO in App Engine myself. What are your thoughts about the performance?
As for the merging part. The GAEContainer does not use the low level API for all interaction with the Datastore. The cache is also designed in a quite specific and low level way. I cant at least at first glance see how to combine the projects. Do you have something in mind?
Can’t comment on JDO performance. I’m not at a point where I’d notice any difference. An important concern, though, is not being completely dependent on the Google datastore and having other databases as an option. Sticking to a standard like JDO or JPA helps with that.
I took a look at your project and didn’t see an obvious way either to integrate them. Perhaps Henri could offer some comments here?
Just posted a significant update to my add-on which allows the data in the GAETable to be edited and persisted back to the datastore. In the first version, the GAETable just displayed all instances of a persisted class by essentially just specifying the class. This current version enables editing.
The add-on now has the following external library dependencies:
There’s one known bug I’m still trying to track down. When you make a change to a table row and then double click on another table row (indicating you want to edit that other table row), the pop-up window asking if you’re sure you want to do that, triggers a NotSerializableException.
Just started using Vaadin and GAEContainer and first of all thanks Johan for this with well commented code
But as I see in sources, it keeps entity count for each kind in in “_size” store. But it relies on that once it is created in datastore and makes trouble when real entity count is different from this number.
I started my app as JDO, so in other parts i just create and persist entities this way and its not really working together.
The for storing entity count as metadata (_size) is that it is very time consuming to get the count for a large number of entities. If the _size does not exist the container counts the entities in the datastore and creates it. The _size entities are transactionally updated on adds and removes by the container. However if you manually add entities after the _size entity has been created this approach will not work.
I haven’t put so much thought into using the container with JDO so there could be other problems as well. As for the _size thing, I can make it customizable so that counting will not use metadata if that helps.
Well customizable or some refresh on demand feature. Other thing is when i remove some items from it, it leaves the row in table, but just makes it smaller.
I’m gonna checkout your sources and do some tweaks myself. I’m really new to all that and that “everithing has to be serializable” thing in vaadin & gae makes it even more confusing to start with it
Other thing is that I cant use it for standard fileds, as you do not support getItemIds(). i know its because of high volumes of data in large datasets, but it would be wery useful for short list (Cities, Lists of other entities for creating relations in forms). It woul mean to load the whole list to memory, but tha would not be that bas, as lot of forms would use this for list tha would have likely tens of items
It would be fine to have that defauld behavior as it is, but availability to configure it for some other use.
I must be pain in the ass, but I prefer perfecting already existing tool, than creating something else.
Posted a significant update to the add-on, which has evolved into something a bit more substantial. I am shooting for a fairly full-featured framework for bridging the gap between Vaadin and Google App Engine (GAE) applications which use the GAE datastore. The standard relied upon is JDO.
The aim is to enable Vaadin-based GAE applications where the main work in building the application is defining the datastore Pojos (classes extending AbstractGAEPojo from the add-on) used by the application.
There is an included demo which allows adding, deleting, and editing a GAEPojo called SimpleBeanableClass. The demo can be viewed online at: http://gaedatastorecontainers.appspot.com/.
JDO is a tough standard to work with. At a certain point I came across Objectify (https://code.google.com/p/objectify-appengine/) which seems really good. The reasons I didn’t end up using it were 1) wanted apps to have the ability to potentially migrate away from GAE, 2) it’s a bit early to see if the Objectify project has staying power, and 3) was too far down the road with JDO already.
However, the introduction to Objectify has this funny line:
“After you’ve banged your head against JDO and screamed “Why, Google, why??” enough times, read the Concepts and then the IntroductionToObjectify.”
I can attest that my head now has lots of bruising.
Thats the exact reason I want to go with JDO. I try not to lock the project on the platform itself. And Johans add-on blew my mind how easy was to get the values to show up in the GUI. With JPA Container it was too much messing around for fast prototyping. Seems like i just found way around my many-to-many relations problem, so looking forward testing it.
For Container, i makes me do a lot of changes in my model so far. On the other hand it looks good. The password filed dependency is unnecessary, especialy if its tied to exact field name.
but as it makes me do lot of changes to my code, its exactly other approach to what I prefer. I makes my model coupled with one special container and would be lot of unnecessary work when migrating just to another component.
Hi,
Is it possible with gaedatastorecontainers to have a form where one of the values to be recorded would have list of values from where the user should choose the one to record?
Johan, in my case the _size entries per each entity get desynchornzied with the entities that are actually in each entity.
So, I have an entity called LIBRARY-ADBDEDR with a number of BOOKS inside.
Each library can hold a few BOOKS and _size entry for the ADBDEDR states that there is 5 BOOKS in LIBRARY.
IN fact there is 12 BOOKS in the LIBRARY-ADBDEDR. GAEContainer IGNORES all 7 entries and ONLY loads 5.
As a result my entire app is getting wacked. Adding an option to AVOID using the _size entity with entries denoting number of books per LIBRARY
would really be in order…
I am thinking of modifying it myself at apoint unless we have a better solution already in place.
In FACT, I am planning to have millions of LIBRARY entities and each will have only a few BOOKS.
In this case the _size entity would have to be CONSTANTLY updated with info on number of BOOKS in each LIBRARY…
Any suggestions would be appreciated. Initially it took me a while to figure out what is going on…also thanks ot your posts I am realizing that
discrepance between _size entry for a LIBRARY and actual number of entires in the LIBRARY leads to the trouble.
for example FILTERS operate on the ENTIRE LIBRARY size EVEN if it is higher than what is reported in _size table for the given LIBRARY.
=====
I suggest an option to let GAEContainer to operate WITHOUT THE USE of _size but rather having it count entires per each entity.
this works great for LARGE numbers of entities that have few entries.
I just changed it to entirely ignore the _size table. in my case where there is thousands of entities containing a few entries, it makes no sense to keep counters of entries in those entities in one table. maybe I could expose it as a configurability and check in if you like it
