Hmmm...very good points. You've given me something to ponder--I can definitely see the merits of supporting a data-oriented mechanism as you describe.
One point to add: the GAE datastore isn't really like a relational database at all--it's much less strictly organized. It's more like a "bag of CFML structs" where there's no requirement that the structs contain the same keys, but are grouped (arbitrarily, perhaps) into "kinds." If you look at the definition of an Entity it's basically the same as a CFML struct (or a Java Map) with "getProperty", "setProperty", and "removeProperty" methods: http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/datastore/Entity.html So from CFML perspective, I think the basic unit of data you could put into the GAE datastore is a struct. Anyway, let me think this over a bit more. Vince On Fri, Jun 5, 2009 at 3:35 PM, Baz <[email protected]> wrote: > I don't have issue with the serialization, as you said, that's only an > implementation detail. What I want to know, is why the question is about > saving/restoring *CFC's* and not *DATA*? If I deploy OpenBD on AWS, there > is no cfc persistence or built-in ORM, there is only straight > *data*persistence. If I deploy OpenBD to my home server, again there is only > *data* persistence. Why the paradigm shift just for GAE? The problems that > are being solved are the same for any OpenBD flavor, so why not implement it > across the board in that case? > > The GAE datastore is very similar to a relational db, the only significant > difference being that it has the concept of multiple values for a property > and therefore additional/different sql functions. But that characteristic > does not necessarily suggest that we need to bring cfc's into the mix. > > This following code is the heart and essence of CF: > > <cfquery dbtype="google" name="Visitors"> > SELECT FROM Visitor > </cfquery> > <cfoutput query="Visitors"> > #Visitor.IP# > </cfoutput> > > Why dismiss it so quickly? Lots of people don't care to have everything in > an object. And if they do, well they can just do what they always do: > > VisitorObject = new('Visitor'); > VisitorObject.setIP(VisitorQuery.IP); > > And to save that visitor they would just do: > > GoogleWrite('Visitor', VisitorStruct); > > Or: > > GoogleWrite('Visitor, { IP=localhost, Name=Baz }); > > Or perhaps a special UPDATE statement that openbd translates to > googlewrite: > > <cfquery dbtype="google" name="Visitors"> > UPDATE Visitor > SET IP='localhost' > </cfquery> > > If they they wanted an entirely object-oriented app without worrying about > CRUD, they could just harass Mark Mandel to write a GAE Transfer that I'm > sure would be very neat and fabulous :) > > The question is why force someone down that route, and change the paradigm > so significantly, when they can choose to do it themselves if they wanted > to? What am I missing here? > > I see your update to the thread now: > > "Only persist those variables that you (the CFML developer) specifically >> declare to be persistable, via CFPROPERTY or some other annotation >> mechanism. Searching can be done on any persistable variable that is a >> simple type (string, number, boolean, date). When you read a CFC from the >> datastore, create a new CFC instance and populate it with the persisted >> variables." >> > > This is getting even closer to what I am saying. If the data is coming back > in raw form, why don't you just give it back to me like that instead of > adding additional processing to "create a new CFC instance and populate it > with the persisted variables"? What if I don't want a cfc and the extra > overhead of creating it. > > 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 !! -~----------~----~----~----~------~----~------~--~---
