Not too much implementation detail at all, that's exactly what I was wondering.
Baz On Tue, Jun 9, 2009 at 10:24 AM, Vince Bonfanti <[email protected]> wrote: > RE: "Java natural forms," I mean that variable sharing will be transparent > to both Java and CFML programmers, just as it is today for shared variables > in the Session and Application scopes. The way this works under the covers > is that CFML variables get converted into their Java forms for storing in > the shared scope, then back to their CFML forms when referenced by the CFML > developer (maybe I'm getting too much into implementation details here). For > the GAE datastore, just like for the Session and Application scope, these > transformations will betaken care of for you automatically by BD. > > Vince > > On Tue, Jun 9, 2009 at 1:11 PM, Baz <[email protected]> wrote: > >> 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 !! -~----------~----~----~----~------~----~------~--~---
