> > Instead, I store the Google keys for the blogEntry.cfc instances > within the blogCategory.cfc and read the blogEntry.cfc instances only > when needed. >
If you had 10,000 blog entries or more this will probably break the app because you would reach the attribute length limit (which I can't seem to find, what is the max attribute size?). In cases like this, when it comes to OO db's, I think it is recommended to choose the smaller side of the relationship to store your data. So instead of storing all posts that a category is related too in the category object, you would store all categories a post is related to in the post object - there will only be a few categories per post. To retrieve all posts for a certain category then, you would do: SELECT FROM Post WHERE Category = 'App Engine' Baz On Tue, Jun 2, 2009 at 8:45 AM, <[email protected]> wrote: > > > Hi Peter, > > Great question. With the current implementation, all CFCs that compose > a given CFC are serialized along with that CFC. That is, all CFCs that > are referenced within the "this" or "variables" scope of a CFC are > serialized along with that CFC. If you want to avoid this behavior, > you'll have to code around it manually (for example, by removing CFCs > from the "this" or "variables" scope before writing to the datastore, > and then restoring them when reading). As we get more experience and > develop a set of use-cases, we can figure out the right way to handle > this automatically. > > A technique that I'm using while porting BlogCFC is to store the > Google keys of referenced CFCs rather than the CFCs themselves within > the composed CFCs. For example, a blog category--represented by > blogCategory.cfc--contains references to blog entries--represented by > blogEntry.cfc. One way to implement this would be for blogCategory.cfc > to keep an array of blogEntry.cfc instances. But, the problem with > that solution is that blogEntry.cfc instances would get serialized to > the datastore whenever you write a blogCategory.cfc instance, which is > undesirable because a blog entry can belong to multiple categories, > which would result in the blogEntry.cfc instances getting serialized > multiple times (once with each category). > > Instead, I store the Google keys for the blogEntry.cfc instances > within the blogCategory.cfc and read the blogEntry.cfc instances only > when needed. Within the blogCategory.cfc pseudo-constructor I create > an array to hold the Google keys of the blogEntry.cfc instances (I > call the keys "ids" to be consistent with existing blogCFC > terminology): > > <cfset variables.entryIdArray = arrayNew( 1 )> > > Then I declare an "addEntry" function within blogCategory.cfc that > looks like this: > > <cffunction name="addEntry" access="public" returntype="void" > output="false"> > <cfargument name="entryId" type="string" required="true"> > <cfset arrayAppend( variables.entryIdArray, arguments.entryId )> > <cfset googleWrite( this )> > </cffunction> > > The "getEntries" function can be used to retrieve all entries for a > category (note that the GoogleRead function allows you to do a "batch > read" by passing an array of keys, returning an array of CFC > instances): > > <cffunction name="getEntries" access="public" returntype="array" > output="false"> > <cfreturn googleRead( variables.entryIdArray )> > </cffunction> > > Again, as we gain experience and develop a set of use-cases, we may be > able to provide a way to automate this technique. > > Vince > > On Jun 2, 3:12 am, "Peter J. Farrell" <[email protected]> wrote: > > > > This is cool stuff Baz. I'm sure Vince will response on your question. I > > have an additional question. > > > > How is / does Open BD handle the object graph of a CFC (basically a CFC > > has that other CFCs via composition) and deserializing it to the Google > > Datastore? Is that something that will be handled via cfproperty? I'm > > asking because I'm sure there are some CFCs where you want to > > deserialize some, but all not all CFCs via composition (for instance an > > application wide CFC that you an inject after serialization). > > > > Thanks in advance, > > .Peter > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 !! -~----------~----~----~----~------~----~------~--~---
