Sounds excellent. There are so many subjective ways to build an app that someone will always complain if openbd tries to do too much. The more raw, performant and flexible the datatore interaction is, the more useful I think it will be. Frameworks can take care of object models, code arganization and other such details. Maybe I'll even tackle a GAE specific framework or orm if it seems appropriate/beneficial.
Good point on the array-of-structs, a query object would be ridiculous to return, given that one 'kind' (table) can store any type of data simultaneously, be it orders, users or whatever. When you say that cfml variables "would be stored in their Java natural forms", what do you mean exactly? That when GAE is queried, and OpenBD gets an array of java objects, that you will keep it in that form rather than converting it to a cfml array of structs? That's seems great because it keeps it raw, but how, or at what point, would a cfml developer be able to use an array of structs? Or am I misunderstanding completely :) Baz P.S. Looking forward to the code drop tommorow, June 10 On Tue, Jun 9, 2009 at 5:53 AM, Vince Bonfanti <[email protected]> wrote: > I think I accidently said something important in my previous email that > bears repeating, or perhaps restating: The CFML variable type that most > naturally maps to the Google datastore Entity is a "struct." Therefore, what > if we updated the GoogleRead, GoogleWrite, etc. to deal with structs as well > as CFCs? CFQUERY and GoogleQuery would return an array of structs that you > could conceptually think of as rows within a table. The CFML variables would > be stored in their "Java natural" forms, which would allow sharing with Java > code (just as you would share Session variables). > > It seems so simple, really (and is perhaps what you were already thinking, > now that I re-read your sample code). It wouldn't be too hard to implement, > after I wrap up the CFDIRECTORY/CFFILE virtual file system work. What do you > think? > > Vince > On Fri, Jun 5, 2009 at 4:00 PM, Vince Bonfanti <[email protected]>wrote: > >> 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 !! -~----------~----~----~----~------~----~------~--~---
