The work to get OpenBD running on Google App Engine has been going great, and just today we added details to the OpenBD wiki covering how to use the GAE Datastore with OpenBD. Kudos to Vince Bonfanti for all the hard work on this! We should have a downloadable GAE-compatible version of OpenBD available soon.
Since the GAE datastore isn't a relational database, the OpenBD API isn't technically an ORM (Object-Relational Mapping). It's more accurate to describe the GAE datastore as an object database, into which the OpenBD API allows you to store CFC instances.
Hello Matt !
Reading on a Sunday about 'CFML without the ORM hassle' has made me literally cry some
tears of joy :-) ... Because my appetite for the seemingly shining 'Land of OODBMSes' has
been whetted for some while now !
But further reading and thinking about this 'OpenBD CFML GAE Datastore' thingie has
quickly have me sobered ...
What I like about this new avenue:
- The 'kind' approach
- The seemingly sheer simplicity of the GAE Datastore API
What I dislike:
- No 'unequal' operator in the 'where clause'
- Much too little information:
- What about GAE Datastore 'ACID' compliancy ?
- What about cascading deletes and referential integrity ?
Asked another way round: Is it already prime time for this 'OpenBD CFML GAE Datastore'
thingie ? That is can I achieve with this thingie everything as easy - or easier for that
matter - as if using the traditional 'RDBMS with ORM' approach ?
Cheers and Tschüss
Let me try to answer some of your questions for you. Google claims that the datastore is "strongly consistent" but don't really elaborate on this point:
The GAE datastore supports transactions, but this isn't supported by the OpenBD API yet (it will be in the future):
The GAE datastore supports relionships between objects, but this isn't support by the OpenBD API yet (it will be in the future):
With the current OpenBD API, if a CFC contains a reference to another CFC, the referenced CFC is stored as an embedded object within the "parent" CFC. The two CFCs are not stored independently (if you write the "embedded" CFC to the datastore separately from the "parent", the "embedded" CFC will effectively be stored in the datastore twice).
Both the GAE datastore and OpenBD API are at the early stages of development and are sure to evolve and mature as time progresses. The best thing for you to do is use it and let us know what you like and dislike, and how you'd like to see it improved.
Hello Vince !
Thanks for the clarifications; unfortunately I cannot afford myself to play around with evolving solutions; what I need are rock-solid, robust approaches; so I will keep this 'OpenBD CFML GAE Datastore' thingie on my radar, but won't use it as of now.
Thanks and Tschüss
@Vince--thanks for pointing that out. I did debate calling it "ORM" since the "R" is a bit of a misnomer, but it seemed the quickest way to get the point across that you can save CFCs to the GAE Datastore without having to worry about the mechanics of it. Sorry if that caused confusion for anyone.