No, it's not an OpenBD-specific, but a standard Google key created as I described previously. What you're seeing the display is the URL-safe string version of the key.
Vince On Mon, Nov 16, 2009 at 6:01 PM, Bassil Karam <[email protected]> wrote: > Rainer, so I see what you mean now. I never noticed there were 2 keys, but > reading over the docs I now see: > > googleKeyvalue returned from GoogleWrite(). If used, then kind and keyName > must not be used. kindIf used, then googleKey must not be used. kind is > used by this function together with keyName to create a googleKey that is > then used to read the entity from the datastore. keyNameIf used, then > googleKey must not be used. keyName is used by this function together with > kind to create a googleKey that is then used to read the entity from the > datastore. > > So "googleKey" is an OpenBD-specific key that gets returned from > googleWrite() whereas "keyName" is the actual id of the kind as the datstore > sees it. I have a feeling the googleKey is basically hash(kind && keyName) > to make a single uniquely identifiable key that in independent of kind. > > Now for the question of whether this is *good* or not :) > > For one it seems certain that it shouldn't be called "googleKey", as that > is quite misleading, but rather something much closer to > "OpenBD-Specific-Key". I guess the main problem it is trying to solve is to > be able to interact with records without having to specify 2 values ("key" > and "kind") - this is probably especially useful when doing a batch read > using an array of keys, which is much simpler than an array of structs with > "key" and "kind". > > Given all that though, I think I agree with your criticisms Rainer - seems > to add more confusion and complexity than it solves. In the world of > relational db's, you need to know the id AND table name, so people are used > to dealing with both pieces of data. With regards to batch reads, might be > ok to limit that to one kind. So when you provide an array of keys, you know > it is for a single kind. And for a super-advanced version you can provide an > array of structs with kind/key. > > To me, this seems like the most natural flow: > > *dataset for kind USER* > key = 1, name = baz, coolness = high > key = 2, name = rainer, coolness = almost-as-high > > *read* > User.googleRead(2) // reads user "rainer" at key #2 > User.googleRead(2, 'User') // same as above except "kind" is explicitly > specified > Key = googleRead('User', 2) // "key" and "kind" are required when using the > general googleRead() function > > *write* > User.googleWrite() // writes the "rainer" object that was read in previous > statements, no key necessary as it is stored as a property of the cfc > User.googleWrite(1) // overwrites the "baz" record at key #1 with the > "rainier" record because the key was manually specified. (The resulting > recordset would have 2 identical records except with key #1 and #2) > > googleWrite(User) // only cfc is required when using general googleWrite(), > the key is stored in the cfc > > Seems simpler this way, without any roadblocks - thoughts? > > Baz > > -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon mailing list - http://groups.google.com/group/openbd?hl=en !! save a network - please trim replies before posting !!
