The data is very highly dependent on the design of the CFCs, so I'm not sure you'll ever be able to write some sort of generic import tool. It's going to have to be specific to the application. The same is true for Java applications migrating to GAE, by the way, though this could be made easier if the application is written to an object- based API such as JDO or JPA rather than JDBC (SQL). Unfortunately, no such standard CFC-based persistence API exists (yet) for CFML.
I have not received an answer yet to the application scope question. I'm starting to wonder if the answer is that the application scope is *not* shared across instances of your application (basically, you'd have to treat the application scope as "read-only" and initialize it the same way every time--possibly based on configuration files). I'll let you know as soon as a hear something. Regarding relationships: see my earlier posts about storing keys to model a many-to-many relationship between blogEntries and blogCategories (well, I only showed one side, but it's the same in the other direction). It may be possible for BD to handle this "under the covers" perhaps with some hints via persistence annotations. For example, maybe you really could store the blogEntry.cfc instances directly within the blogCategory.cfc "variables" scope, but then BD would serialize the blogEntry.cfc instances individually (not as part of the blogCategory.cfc instance) and manage the keys for you when reading/writing. There are a lot of possibilities; let's get the basic system up and running, see how people use it, and then make some decisions from there. Vince On Jun 2, 12:22 pm, Baz <[email protected]> wrote: > ...snip... > > 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. > > I definitely see that as the systems are fundamentally different. Once > someone does figure out their new model, though, they will have to *upload* > the data through openbd, rather than some independent import tool, because > they will need the serialized cfc's. Something along the lines of looping > through a csv and populating a cfc then GoogleWriting() it. This tightly > couples the datastore with OpenBD, which could make it awkward if, perhaps, > you have a huge app that also uses, for example, straight java or groovy, > ontop of OpenBD. Maybe the raw data should be stored in clean, separate > *tables* and OpenBD creates its own indexes with serialzed cfc's that > references them? But then if other apps are referencing the same data how > can you be sure the serialized cfc is in synch. Complicated. There are some > ORM aspects to this solution, which makes OpenBD life easier, but I am > concerned that perhaps this is not the proper layer to do it in. Just some > thoughts. > > 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. > > That would be excellent. Did you ever figure out how the application scope > works? Is that saved in memcached? > > [Relationships are] on the TODO list. > > Modelling relationships is going to be very interesting too. Non-trivial. > What ideas do you have? > > Thanks a lot for excellent answers to my numerous questions! > > Baz --~--~---------~--~----~------------~-------~--~----~ 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 !! -~----------~----~----~----~------~----~------~--~---
