One more thing... Serialization is the best (only?) way for us to persist a CFC and guarantee to restore its state exactly we you read it back out again. So, yes, sharing persistent data with Java or Groovy code could be tricky. Of course, the CFCProxy already exists for invoking CFCs from Java code, so maybe that mechanism could be enhanced. Or, we're already able to share session scope variables between CFML and Java (including complex types such as arrays and structs), so maybe that could be the basis for sharing persistent data.
Vince On Jun 2, 12:22 pm, Baz <[email protected]> wrote: > ...snip... > > 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. > --~--~---------~--~----~------------~-------~--~----~ 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 !! -~----------~----~----~----~------~----~------~--~---
