I'm glad you're excited about OpenBD/CFML on GAE--I am too! You ask lots of good questions, and I've done my best to answer them (inserted, below). Let me know if you have any follow-up.
Vince On Jun 1, 4:58 pm, Baz <[email protected]> wrote: > ...snip... > > The datastore has types like strings, ints, floats, etc. Are you serialzing > the entire cfc and storing it as a string in one column, or are you breaking > apart the cfc and storing each property in it's own field? If it's the > former, then how do you allow querying individual properties without loading > the entire recordset to memory? And if its the latter, can you publish the > translation map from cf types to google types that you are using. Very > interesting how you did this and the more I think about it the more unlikely > it seems that you are serialzing it into an arbitrary string that has no > context in google. We do both. The entire CFC is serialized into a Blob (a byte array); as you may know from the GAE documentation, Blobs are not indexed and you can't search on them. Then, all of the simple variables (number, boolean, string, and date) in the CFC "this" and "variables" scope are stored as properties that you can search on. The translation map is very simple: CFML type Java type --------- --------- number java.lang.Integer or java.lang.Double boolean java.lang.Boolean string java.lang.String date java.util.Date We've discussed the possibility of using the CFPROPERTY tag to define properties that are stored separately for searching, instead of storing everything in the "this" and "variables" scope. We'll have to see if there's any benefit of doing that. > > If I query the datastore and get back an array of 1000 objects, are each of > those objects created using createObject (or similar)? If so, don't we > potentialy run into the createobject slowness that has spawned IBO's and > other work-arounds? First, BD has nevered suffered from the createObject performance penalty that Adobe ColdFusion has. Nevertheless, the fact that we're serializing the entire CFC means that deserialization is very fast-- we're not reconstructing the CFC from it's constituent parts. Note that it's the *entire* CFC that's being serialized--code and data, not just data as in most other ORM-style schemes. (A side-effect of this is that if you use method-injection to add methods to your CFC, those methods survive the serialization/de-serialization process--pretty cool). Also, we haven't even begun to look at potential optimizations yet. > > Is it possible to get straight queries of simple types from the datastore? > If everything is fast enough this may not even be needed, but just > wondering... That's an interesting thought that we should consider. > > How do you recommend seeding the datastore with inital data? Like if I had > an old relational db that I wanted to migrate over... That's not going to be straightforward at all. The GAE datastore is inherently object-orienced (CFC-oriented for us CFML types), and not relational at all. I've been working on porting BlogCFC to OpenBD/GAE, and it's very enlightening to see the difference an object-oriented model has on the organization of the code and how you think about the flow of control and interactions with the database/datastore versus a relational model. The bottom line is that I think it's going to take some custom code to migrate the BlogCFC data (for example) from a relational database to the GAE datastore. I expect there may be an opportunity for some consulting services in that area, and I expect to position New Atlanta to be able to provide those services. > > How do you handle updates to the google API? Does every update have to be > coded-in to OpenBD or, if the update is simple (like a new operator was > added) will OpenBD automatically get it because it is simply proxy'ing > requests to the underlying java? It really depends on what changes they make. > > Do you recommend storing objects in a persistent scope like application or > session to minimze requests and access to the datastore, or is the datastore > designed to be that persistent scope accessed on every request? GAE provides an API to memcache and I expect we'll use that to implement a query caching layer, adding support for the CACHEDWITHIN attribute to CFQUERY, for example. All the caching features currently available in BD (and CFML in general) should be available on OpenBD/ GAE. > > Whats the word on relationships and lists of multiple values for a single > attribute? It's on the TODO list. > > What about transactions? Also on the TODO list. --~--~---------~--~----~------------~-------~--~----~ Open BlueDragon Public Mailing List http://groups.google.com/group/openbd?hl=en official site @ http://www.openbluedragon.org/ !! save a network - trim replies before posting !! -~----------~----~----~----~------~----~------~--~---
