Agenda

• dojo.data.Result API
  1. how do we want to handle GUIs that page or scroll through large result sets?
     • explicitly encourage data stores like the YahooStore example?
     • explicitly discourage or forbid that type of iteration?
     • other alternatives?
  2. clarify: run multiple foreachs run serially not in parallel?
     • [adamsz: serial]
     • [skinner: serial only]
     • [mitchell: serial (on the same result set instance)]
  3. what does inProgress() mean?
     • forEach() loop is in progress?
     • data is loading (query has been sent, forEach() not yet called)?
     • either of the above?
     • ~[adamsz: for clarity maybe instead we should have a state member;
       • i think we need: initial, receiving, completed, error
       • compare with:
       • xmlhttprequest.readyState: 0 uninitialized, 1 open, 2 sent, 3 receiving, 4 loaded,
       • deferred.fired: -1 initial, 0 success, 1 error
       • ]~
     • [skinner: Having a state property seems like a good idea. Should the state property convey info about (a) progress loading data from the server (initial, receiving, completed), or (b) progress iterating through the forEach loop (initial, looping, completed), or (c) some combination of both? What's the name of the state property, and do we want some sort of getState() accessor method]
     • [mitchell: State member is good, for determining resultset state between store (local or remote) and JS client]
  4. signature for oncompleted callback?
     • [adamsz: oncompleted(iterator)]
     • [skinner: oncompleted(). We might consider passing an iterator to the callback method that the caller sets with setOnLoopCompleted(callback). We should not pass an iterator to the callback method that the caller sets with setOnFindCompleted(callback), since that doesn't work well with the style of access that we might want to do in paging/scrolling implementations like the YahooStore. Offering a synchronous-iterator creates a new implementation requirement that dictates that all results will be in memory at once. Synchronous looping is a nice feature to have, but we shouldn't impose the the all-results-in-memory requirement every time a find() is complete, as would be required if we automatically pass an iterator in to the oncompleted callback -- we should only impose the the all-results-in-memory requirement if the calling code explicitly asks for synchronous looping by calling a asIterator() or asArray() method. If we do have a asIterator() or asArray() method, I have a strong preference for asArray() instead of asIterator(), because looping through an array is something that every JavaScript textbook covers, whereas the iterator syntax is dojo-specific and less obvious.]
     • [mitchell: onCompleted(). We may also want to consider whether it makes sense to use "well known" topics for store or data events. Eg., dojo:data/store/yahoo1/recieving or dojo:data/store/yahoo1/valueChanged]

• dojo.data.Read API
  1. get() returns undefined if attribute is present but has no values?
     • [mitchell: +1, undefined = not set]
  2. getValues() returns [] if attribute is present but has no values?
     • [adamsz: i think there should be no distinction between attribute existence and an attribute having no values. So getValues() should return undefined in this case. If an attribute was set to null it would return [null]. ]
     • [mitchell: agree with adam]
     • [skinner: I agree that there should be no distinction between attribute existence and an attribute having no values. I think that getValues() should return an empty array in this case, so that the calling code doesn't have to check to see whether or not an array was returned.]
  3. remove hasAttributeValue()?
     • [adamsz: no]
     • [mitchell: Not sure, isn't this the same as get() === undefined?]
  4. change getByIdentity() to findByIdentity(), as per suggestion in mail from Adam Souzis?
     • [mitchell: +1]
  5. findByIdentity() always synchronous?
     • [mitchell: ?]
  6. move getIdentity() and findByIdentity() out of dojo.data.Read (maybe into dojo.data.Identity)?
     • [adamsz: yes]
     • [mitchell: +1]
  7. have findByIdentity() return null if no item is found, rather than throwing an excpetion?
  8. find(query, {async:true}) vs. find(query, {sync:false})
     • just support 'async', or just 'sync', or both?
     • default to {async:false}?
     • [adamsz: just support 'sync' (match bind keyword)]
     • [adamsz: default to {sync:true}]
  9. semantics of isItem() more like isItemAvailable() (and, if so, rename it)?
     • should isItem(x) return true if x is an item Identity instead of an item?
     • should isItem(x) return true if x is an item that has been deleted? Prior to a save? After a save?
     • [adamsz: yes to all these]
     • [skinner: yes for deleted items. no if x is an item Identity, not an item. If isItem(x) returns true when x is an item Identity, that makes it impossible to use isItem() to figure out what a call to store.get() has just returned, and so you can't write GUI display code.]
     • [mitchell: How about isItem(any) for type-check, exists(item) for existence test?]

• dojo.data.Write API
  1. save()
     • store.save({async: true})?
     • store.save({async: true, onComplete: callback});
     • always return a Deferred, or sometimes a boolean?
     • default to sync, not async?
     • [adamsz: save({sync:true}), always return Deferred (test result.fired for success) ]
  2. include methods add() and remove()
     • store.set(kermit, color, "green");
     • store.add(kermit, color, "blue");
     • store.add(kermit, color, "aqua", {at: 0});
     • store.add(kermit, color, "cyan", {after: "blue"});
     • store.remove(kermit, color, "green");
     • [adamsz: ok, but lets name them add/removeValue. And significance of order and whether duplicate values are allowed should be implementation dependent. also, clarify that removeValue removes all matching values if there are duplicates.]
     • [mitchell: +1, clarify that add with no optional 4th parm adds at end of value list, and at can be used for remove as well.]
  3. should isDirty() with no args returns whether the current transaction is dirty?
     • [adamsz: yes]
     • [skinner: Why not isDirty(store), as per the current documentation, rather than isDirty()? Or are you saying we should support isDirty() and isDirty(store), with different semantics?]
     • [mitchell: 0, could we move this to change-tracking interface?]
  4. should dojo.data.Write include (extend) dojo.data.Read?

• add new code (where?, minor code style stuff first?)
  1. check in RemoteStore?
  2. check in mockXmlHttpRequest?
  3. move dojo.data.csv.Result out of .csv, for re-use?
     • [adamsz: yes, rename to something like SynchronousResult]
     • [mitchell: yes, assuming it's in sync with latest api]

• wait to sign off on some APIs (Read/Result/Write) until after we have some lessons learned from trying initial implementations?
  • • [mitchell: yes]

Resolutions

dojo.data.Result API

• A single result object may only have one forEach() loop running at a time. If your code calls result.forEach() while a loop is already running, that should be considered a bug in your code -- the result object may throw an exception. If you have two different result objects, it's okay to call forEach() on both objects at the same time and have the loops running in parallel.

dojo.data.Read API

• store.get() returns undefined if the item does not have a value for the given attribute. Saying "the item does not have a value for that attribute" is identical to saying "the item does not have that attribute". It is an oxymoron to say "that attribute is present but has no values" or "the item has that attribute but does not have any attribute values"
• store.getValues() returns [] if an item does not have attribute (when the item has no values for that attribute)
• We will rename store.hasAttributeValue() to be store.containsValue(), and we will include containsValue() in dojo.data.Read
• We will rename store.getByIdentity() to be store.findByIdentity()
• store.findByIdentity() will always return either an item or null (it will never return a Deferred) Implementations of findByIdentity() may sometimes return an item from a local cache and may sometimes fetch an item from a remote server, in which case the call to findByIdentity() will block until the findByIdentity() implementation has the item to return.
• We will move getIdentity() and findByIdentity() out of dojo.data.Read and into dojo.data.Identity.
• store.findByIdentity() will return null if no item is found, rather than throwing an excpetion.
• All implementations of store.find() should accept {sync:true} and {sync:false} as valid optional parameters. We'll standardize on "sync", not "async". If no {sync:} parameter is specified, the default is {sync:true}.

dojo.data.Write API

• We will rename store.clear() to be store.unsetAttribute()
• We will rename store.hasAttributeValue() to be store.containsValue()

Transcript

[1:00 PM] ttrenka: hey brian_skinner
[1:00 PM] ttrenka: i'm gonna lurk, if that's ok
[1:00 PM] brian_skinner: hey ttrenka
[1:00 PM] brian_skinner: yup, you bet
[1:01 PM] ttrenka: i'm at a point (finally) where I can start really debugging some major charting stuff, and I don't want to stop.
[1:01 PM] ttrenka: i'm pretty much with adam on most of the agenda, too.
[1:01 PM] ttrenka: so...no worries :)
[1:01 PM] brian_skinner: okay, sounds good
[1:01 PM] ttrenka: I'm working in a VM so if you want me, say my name
[1:01 PM] ttrenka: colloquy should warn me with a sound
[1:01 PM] brian_skinner: do you want to mark the agenda items where you differ from adam?
[1:02 PM] ttrenka: i don't think I differed from him at all
[1:02 PM] ttrenka: to be honest.
[1:02 PM] brian_skinner: okay
[1:04 PM] -->| aszs (n=chatzill@h-74-0-32-234.snfccasy.covad.net) has joined #dojo-meeting
[1:04 PM] aszs: hi
[1:04 PM] =-= jeffrey_afk is now known as JeffreyH
[1:04 PM] brian_skinner: hey aszs
[1:04 PM] brian_skinner: hey JeffreyH
[1:04 PM] JeffreyH: hello
[1:04 PM] -->| jaxsphere (n=chatzill@cpe-024-211-156-070.nc.res.rr.com) has joined #dojo-meeting
[1:04 PM] jaxsphere: hi all
[1:04 PM] brian_skinner: hey jaxsphere
[1:05 PM] brian_skinner: i think we have a quorum
[1:05 PM] jaxsphere: i just updated the issues list with positions on each
[1:05 PM] brian_skinner: ttrenka will be mostly lurking today, working on debugging his chart code
[1:05 PM] jaxsphere: k
[1:06 PM] jaxsphere: http://dojo.jot.com/2006-10-03
[1:06 PM] brian_skinner: i want to add one more agenda item, one sec
[1:07 PM] brian_skinner: okay
[1:07 PM] brian_skinner: sorry for the delay
[1:07 PM] jaxsphere: how about an agenda item to discuss the paging impl patches that were posted on the list
[1:08 PM] brian_skinner: running behind today
[1:08 PM] brian_skinner: jaxsphere: yup, that's what I just added :-)
[1:08 PM] jaxsphere: ;)
[1:08 PM] brian_skinner: if you reload the agenda you should see that as item #1
[1:08 PM] aszs: that #1 now, do you want to start?
[1:08 PM] aszs: there
[1:09 PM] aszs: or tackle the easier things first?
[1:09 PM] jaxsphere: let's weed out all the ones we agree on first :)
[1:09 PM] aszs: ok
[1:09 PM] brian_skinner: okay
[1:09 PM] aszs: #2
[1:09 PM] aszs: we all agree, right
[1:09 PM] brian_skinner: serial
[1:09 PM] brian_skinner: resolved
[1:10 PM] brian_skinner: wait, jaxsphere -- what do you mean by "on the same result set instance"
[1:10 PM] aszs: that different results may run in parallel?
[1:11 PM] aszs: i agree
[1:11 PM] jaxsphere: if multiple result sets executing async... oh, it will be serial
[1:11 PM] aszs: if i call find() twice with async = true
[1:11 PM] jaxsphere: y
[1:11 PM] aszs: they may execute in parallel
[1:11 PM] brian_skinner: multiple result sets potentially in parallel -- single result set always serial
[1:11 PM] aszs: yes
[1:11 PM] brian_skinner: sounds good
[1:12 PM] brian_skinner: next?
[1:12 PM] aszs: want to try #3?
[1:12 PM] jaxsphere: sure
[1:12 PM] brian_skinner: scary
[1:12 PM] jaxsphere: i dont think it should be state of iteration
[1:13 PM] jaxsphere: but state of io progress between client and store make sense
[1:13 PM] aszs: yes
[1:13 PM] brian_skinner: what do we anticipate the GUI code using this info for?
[1:13 PM] aszs: same way deferred.fired is used
[1:13 PM] jaxsphere: status indication
[1:14 PM] aszs: we could call it readState to match xmlhttprequest
[1:15 PM] brian_skinner: so for status indication, if you want to show the user a spinning "loading" icon until all the results show up in the UI, then what you really care about is the forEach() loop having completed, no the client/server io having completed
[1:15 PM] jaxsphere: you may want to show that the server is processing...
[1:15 PM] brian_skinner: and if you want to avoid starting a parallel forEach() loop, what you need to know about is whether the first forEach() loop has finished
[1:16 PM] brian_skinner: jaxsphere: yup, you might want that info too
[1:16 PM] brian_skinner: but i can't imagine a case where that's the *only* info you want
[1:17 PM] aszs: i think it should only be used for async results
[1:17 PM] aszs: sync results should always return in the either completed or error state
[1:17 PM] jaxsphere: so asyncReadState
[1:17 PM] jaxsphere: ?
[1:17 PM] brian_skinner: aszs: +1
[1:18 PM] aszs: i like readyState
[1:18 PM] brian_skinner: wait: +0
[1:18 PM] aszs: its will known
[1:18 PM] aszs: well known
[1:18 PM] jaxsphere: +1
[1:18 PM] jaxsphere: readyState
[1:18 PM] brian_skinner: the sync vs. async return value depends on whether we're only talking about server io vs. talking about looping
[1:18 PM] jaxsphere: only applies to async
[1:20 PM] aszs: yes
[1:20 PM] aszs: loops execute serially
[1:20 PM] aszs: we just agreed to that
[1:21 PM] brian_skinner: a single loop, forEach(foo), may call foo 100 times
[1:21 PM] brian_skinner: within foo, what is the value of the state?
[1:22 PM] brian_skinner: for example, if foo() calls a method, displayResultsInWindow()
[1:22 PM] brian_skinner: and displayResultsInWindow() wants to kick off another forEach() loop
[1:23 PM] brian_skinner: or wants to know when all the results have been looped over
[1:24 PM] brian_skinner: ...
[1:25 PM] brian_skinner: i don't mean to be slow, but i'm still not getting why the UI code cares about whether the client/server io is finished -- seems like the UI code cares much more about whether the loop is finished
[1:25 PM] aszs: let's drop state for now
[1:25 PM] brian_skinner: okay
[1:26 PM] brian_skinner: dojo.data.Read, agenda item #1
[1:26 PM] brian_skinner: ?
[1:26 PM] aszs: +1
[1:26 PM] jaxsphere: y
[1:26 PM] brian_skinner: +1
[1:26 PM] brian_skinner: resolved
[1:27 PM] aszs: item #2 -- i'm okay either way
[1:27 PM] aszs: either [] or undefined
[1:27 PM] brian_skinner: i vote for []
[1:27 PM] brian_skinner: easier for the client code
[1:27 PM] jaxsphere: client code will be simpler for [].  switching to +1
[1:28 PM] brian_skinner: resolved
[1:28 PM] brian_skinner: ?
[1:28 PM] aszs: item #3
[1:28 PM] jaxsphere: agree with brian on []
[1:28 PM] jaxsphere: Read:#3
[1:28 PM] aszs: i don't know if its totally necessary
[1:29 PM] brian_skinner: doesn't seem totally necessary -- doesn't seem like huge bloat either
[1:29 PM] jaxsphere: well, if get() and getValues() return undefined, then this seems unnecessary
[1:29 PM] brian_skinner: i'm fine either wa
[1:29 PM] brian_skinner: way
[1:29 PM] jaxsphere: how to tell the difference between empty list and unset for a multivalued attr?
[1:30 PM] aszs: if an attribute has multiple values hasAttributeWay tests if value is in the list, right?
[1:30 PM] brian_skinner: hasAttribute() or hasAttributeValue()?
[1:31 PM] brian_skinner: sorry, hasAttributeValue()
[1:31 PM] aszs: jaxsphere: your thinking of hasAttribute()
[1:31 PM] brian_skinner: yes, it tests to see if the value is in the list
[1:31 PM] aszs: hasAttribute() == false is the same as getValues() == []
[1:32 PM] brian_skinner: aszs: right
[1:32 PM] brian_skinner: but I think we should keep hasAttribute() anyway -- it makes the code easier to read
[1:32 PM] aszs: yes
[1:32 PM] jaxsphere: is there a way to unset an attribute value?
[1:33 PM] aszs: what do u mean?
[1:33 PM] jaxsphere: set value back to undefined (as if value never specified)_
[1:33 PM] brian_skinner: store.clear(kermit, "color")
[1:33 PM] aszs: or setValues(attr, [])
[1:33 PM] jaxsphere: oops, looking at Read
[1:34 PM] aszs: maybe clear() should be called clearAttribute?
[1:34 PM] aszs: clearer
[1:34 PM] aszs: or removeAttribute()
[1:34 PM] jaxsphere: or unset
[1:34 PM] aszs: y
[1:34 PM] aszs: unsetAttribute()
[1:34 PM] brian_skinner: i'm fine with any of those
[1:34 PM] jaxsphere: unsetAttribute() +1
[1:34 PM] aszs: +1
[1:34 PM] brian_skinner: resolved.
[1:35 PM] aszs: maybe rename hasAttributeValue() too?
[1:35 PM] brian_skinner: okay, to what?
[1:35 PM] jaxsphere: isValueSet()
[1:35 PM] aszs: hmm
[1:36 PM] aszs: something to emphasis "one of"
[1:36 PM] aszs: valueInAttribute?
[1:36 PM] aszs: containsValue()
[1:36 PM] jaxsphere: containsValue()
[1:36 PM] jaxsphere: :)
[1:37 PM] aszs: +1
[1:37 PM] brian_skinner: store.containsValue(kermit, "color", "green)
[1:37 PM] brian_skinner: okay
[1:37 PM] brian_skinner: resolved.
[1:37 PM] jaxsphere: y
[1:37 PM] aszs: move identity functions to another interface?
[1:37 PM] aszs: +1
[1:38 PM] jaxsphere: y
[1:38 PM] jaxsphere: +1
[1:38 PM] brian_skinner: so, that implies that we are keeping store.containsValue() in the API, yes?
[1:38 PM] brian_skinner: :-)
[1:38 PM] aszs: yes
[1:38 PM] brian_skinner: item #3 resolved
[1:39 PM] jaxsphere: how about #6, naming of identity interface?
[1:39 PM] jaxsphere: dojo.data.Identity+1
[1:39 PM] aszs: +1
[1:39 PM] brian_skinner: okay
[1:39 PM] aszs: should we skip the other identity questions now that there not in these Interfaces?
[1:40 PM] brian_skinner: so we just resolved #4 and #6?
[1:40 PM] brian_skinner: sorry, the scribe is having trouble keeping up :-)
[1:40 PM] aszs: #6 if you agree
[1:40 PM] aszs: +1 on #4
[1:40 PM] jaxsphere: +1 on #4
[1:40 PM] brian_skinner: yup, i'm fine with dojo.data.Identity
[1:41 PM] brian_skinner: and i'm fine wtih findByIdentity()
[1:41 PM] jaxsphere: can someone explain 5?
[1:41 PM] aszs: if findByIdentity might invoke a remote query
[1:41 PM] brian_skinner: findByIdentity() may need to make a call to the server to load the item
[1:41 PM] jaxsphere: immediate return
[1:41 PM] aszs: then should it be optionally async?
[1:42 PM] aszs: ok
[1:42 PM] jaxsphere: oh, if you have the identity of an item (from some prev iteration stored away), and you want to get back to that item...
[1:42 PM] brian_skinner: by "immediate return", do you mean return a Deferred?
[1:42 PM] jaxsphere: but item no longer in memort
[1:42 PM] brian_skinner: jaxsphere: yup
[1:42 PM] jaxsphere: Deferred
[1:43 PM] aszs: hmm,
[1:43 PM] aszs: not sure about that
[1:43 PM] brian_skinner: always return a Deferred?  even though 99% of the time the item will already be in memory?
[1:43 PM] aszs: maybe if you care about async just use find()
[1:43 PM] jaxsphere: ok with that
[1:43 PM] aszs: with the equivalant query
[1:43 PM] brian_skinner: aszs: that sounds good to me too
[1:44 PM] jaxsphere: keep key vals, rather than ident
[1:44 PM] brian_skinner: so findByIdentity() always returns an item
[1:44 PM] jaxsphere: and reexecute query
[1:44 PM] aszs: or null
[1:44 PM] brian_skinner: or null
[1:44 PM] jaxsphere: undefined...for item not in memory?
[1:44 PM] brian_skinner: and findByIdentity() may block, waiting for the server?
[1:44 PM] aszs: brian: yes
[1:45 PM] aszs: up to the implementation
[1:45 PM] brian_skinner: i'd vote for null rather than undefined, but no strong preference
[1:45 PM] brian_skinner: null seems easier to check for
[1:46 PM] jaxsphere: null
[1:46 PM] jaxsphere: ok
[1:46 PM] aszs: yes, lets leave undefined undefined
[1:46 PM] aszs: ;)
[1:46 PM] jaxsphere: ;)
[1:46 PM] brian_skinner: okay, resolved
[1:46 PM] aszs: looks we resolved 4 thru 7
[1:47 PM] brian_skinner: didn't we resolve 1 to 3 also?
[1:47 PM] aszs: yes
[1:47 PM] brian_skinner: okay
[1:47 PM] aszs: not 1
[1:47 PM] aszs: we skipped that
[1:48 PM] aszs: oops sorry
[1:48 PM] jaxsphere: find(query,{sync:false})
[1:48 PM] aszs: yes 1-3 in Read
[1:48 PM] aszs: +1
[1:48 PM] jaxsphere: +1
[1:48 PM] brian_skinner: right, resolved 1-7 in Read
[1:48 PM] aszs: the default for sync should be true?
[1:48 PM] brian_skinner: yes
[1:48 PM] jaxsphere: y
[1:49 PM] brian_skinner: okay, resolved
[1:49 PM] aszs: #9 -- i mistyped
[1:49 PM] brian_skinner: what did you mean to type?
[1:49 PM] aszs: i meant to say that i think isItem(x) should return false if delete
[1:50 PM] aszs: deleted
[1:50 PM] brian_skinner: okay, i'm fine with that too
[1:50 PM] brian_skinner: false if deleted but not saved?
[1:50 PM] jaxsphere: so is isItem both type check and existence check?
[1:51 PM] aszs: i think so but maybe implementation dependent
[1:51 PM] brian_skinner: what do you mean by an existence check?
[1:51 PM] jaxsphere: meaning does the item passed in exist
[1:51 PM] aszs: "there is no guarantee that isItem() will return true if the item has been deleted"
[1:51 PM] jaxsphere: (if it is an Item)
[1:51 PM] aszs: jaxsphere: yes both
[1:51 PM] brian_skinner: how would you ever have a handle to an item that doesn't exist?
[1:52 PM] jaxsphere: how about split to 2 ops? exists(item) and isItem(any)
[1:52 PM] aszs: in RemoteStore there's no way i can tell since my item reference is just a string
[1:52 PM] jaxsphere: exists(item | identity)
[1:53 PM] aszs: hmm, actually that not true
[1:53 PM] jaxsphere: you mean for the type check?
[1:53 PM] brian_skinner: so, exists(identity) may require a trip to the server, whereas isItem(item) is always knowable on the client?
[1:53 PM] aszs: sorry i mean my statement that in Remote store item is just a string is not true
[1:54 PM] jaxsphere: i think the exists(...) should move to Identity interface
[1:54 PM] aszs: the reason i suggested renaming it to isItemAvailable()
[1:55 PM] aszs: is to make it clear that this just test whether the object is a "usable" reference
[1:55 PM] brian_skinner: i think findByIdentity() may be enough -- we might not even need exists() -- but if we do have exists(), i agree that it should be in dojo.data.Identity
[1:55 PM] aszs: what exactly means is up to the implementation
[1:56 PM] jaxsphere: so isItem(something) should just be a type check
[1:56 PM] jaxsphere: no remote
[1:56 PM] aszs: yes
[1:56 PM] aszs: but more than a type check
[1:56 PM] brian_skinner: aszs: i understand that RemoteStore uses strings for both items and identities, but in general that may not be the case, and i think in general the APIs should try to make a firm distinction between the notion of an item and the notion of an identity
[1:56 PM] brian_skinner: all items, by definition, are available
[1:57 PM] brian_skinner: so isItem() is then just a type check
[1:57 PM] jaxsphere: isItem(getIdentity(item)) always === false
[1:57 PM] aszs: no more i think
[1:58 PM] aszs: consider:
[1:58 PM] aszs: store.get(item, 'attribute')
[1:58 PM] aszs: what if item is an Item type
[1:58 PM] aszs: but the item isn't part of the store
[1:58 PM] aszs: on the client
[1:58 PM] aszs: than get() throws an exception
[1:59 PM] aszs: according to the spec
[1:59 PM] aszs: to avoid that,
[1:59 PM] aszs: isItem() needs to test for availability in the store
[1:59 PM] brian_skinner: i see
[1:59 PM] brian_skinner: yes
[1:59 PM] brian_skinner: it's not just a type check
[1:59 PM] brian_skinner: it's a type check within the context of a store
[1:59 PM] brian_skinner: here's the case where I think isItem() is useful
[2:00 PM] brian_skinner: if you have a book
[2:00 PM] aszs: yes, that's why i think isItemAvailable() is more clear
[2:00 PM] brian_skinner: you have a book, theHobbit
[2:00 PM] brian_skinner: theHobbit is an item
[2:00 PM] brian_skinner: and you want to get the author
[2:00 PM] brian_skinner: so you do
[2:00 PM] brian_skinner: var author = store.get(theHobbit, "author")
[2:01 PM] brian_skinner: and you want to display the author's name
[2:01 PM] brian_skinner: dojo.debug(author)
[2:01 PM] brian_skinner: but you don't know whether author is a string, or a number, or an item
[2:01 PM] brian_skinner: so you need to do stuff like
[2:01 PM] jaxsphere: do you get a value, or an Item reference?
[2:01 PM] brian_skinner: dojo.lang.isString(author)
[2:01 PM] brian_skinner: store.isItem(author)
[2:01 PM] aszs: yes that's true
[2:01 PM] jaxsphere: isReference(author)
[2:02 PM] brian_skinner: and in that context, isItem() seems to make more sense than isItemAvailable()
[2:02 PM] aszs: if author is a reference, does store.get(author, 'attr') throw an exception?
[2:03 PM] brian_skinner: maybe I shouldn't have assumed this, but I always assumed that store.get(theHobbit, "author") would return an actual item, never an Identity or a reference or something
[2:03 PM] jaxsphere: we never specified how to deal with refs
[2:03 PM] aszs: you mean an item with all its attributes available?
[2:03 PM] brian_skinner: aszs: yes
[2:03 PM] aszs: we can't do that
[2:04 PM] aszs: that could suck in the whole store
[2:04 PM] aszs: on the server
[2:04 PM] brian_skinner: it could work like findByIdentity()
[2:05 PM] brian_skinner: it may trigger a small query that gets sent to the server, but it blocks until it gets a reply
[2:05 PM] aszs: you mean get() would invoke a query if the item is reference
[2:05 PM] aszs: hmm,
[2:05 PM] brian_skinner: get() *might* invoke a query if the item is a reference
[2:05 PM] aszs: i don't like that
[2:05 PM] jaxsphere: this gets into more complex get behavior than what we've spec'd so far.  Get will end up requiring identity interface
[2:06 PM] aszs: i rather it throw an exception
[2:06 PM] aszs: we could have both isItem and isItemAvailable()
[2:07 PM] aszs: btw, remotestore does have a notion of references
[2:07 PM] brian_skinner: okay, so do we want to say that store.get(theHobbit, "author") might return either an item or an Identity, depending on whether the tolkien item happens to have been loaded from the server already?
[2:07 PM] aszs: no
[2:08 PM] brian_skinner: okay, so what should store.get() do?
[2:08 PM] aszs: there should be two separate notions of items
[2:08 PM] aszs: should *not* be  i mean
[2:08 PM] brian_skinner: store.get() always returns an Identity?
[2:09 PM] aszs: what an Identity?
[2:09 PM] aszs: i don't think that should be in the Read api
[2:09 PM] aszs: get returns an item
[2:09 PM] brian_skinner: an Identity is the thing that you pass to findByIdentity()
[2:09 PM] brian_skinner: okay, so store.get() always returns an item?
[2:09 PM] aszs: but that's not in the Read API
[2:10 PM] aszs: yes, you can test whether the item is available or not
[2:11 PM] brian_skinner: okay, so then you're saying that you should never do store.get(kermit, "color") until you've first checked store.isItemAvailable(kermit)?
[2:11 PM] aszs: there a difference between an object reference and Identity
[2:11 PM] jaxsphere: apologize, but i have to go now
[2:11 PM] aszs: identity is a key
[2:11 PM] aszs: not all stores have keys
[2:11 PM] brian_skinner: jaxsphere: okay, thanks for coming!
[2:11 PM] aszs: no worries
[2:11 PM] aszs: yes, thanks
[2:12 PM] jaxsphere: good meeting today.  that was a good thing posting positions before hand
[2:12 PM] brian_skinner: yup, that was a good iea
[2:12 PM] brian_skinner: idea
[2:12 PM] jaxsphere: ttyl
[2:12 PM] brian_skinner: see ya
[2:12 PM] aszs: maybe we should table the identity/reference things for now
[2:12 PM] aszs: bye
[2:12 PM] <--| jaxsphere has left #dojo-meeting
[2:13 PM] brian_skinner: aszs: yes, maybe so, with jaxsphere and ttrenka both not here
[2:13 PM] aszs: yes, and a hard issue
[2:13 PM] brian_skinner: ...going away, back in 1 minute
[2:13 PM] aszs: ok
[2:15 PM] brian_skinner: sorry
[2:15 PM] brian_skinner: back again
[2:15 PM] aszs: hi
[2:16 PM] aszs: there's a whole bunch of issues with identity that i've been afraid to broach
[2:16 PM] aszs: hopefully we can avoid them in the
[2:16 PM] aszs: basic apis
[2:16 PM] aszs: for example, if the primary key of a table is say your SS #
[2:16 PM] brian_skinner: yup -- i've been nervous all along about the question of what exactly store.get(theHobbit, 'author') returns
[2:17 PM] aszs: and you call store.set(item, 'SS', another #)
[2:17 PM] aszs: did you just change the Identity of the item?
[2:17 PM] aszs: what if another item reference had that SS#
[2:17 PM] aszs: does it "switch over" to that record?
[2:17 PM] aszs: etc.
[2:18 PM] brian_skinner: if SS# is being used as a primary key, i think most datastore implementations would consider it an error to try to do store.set(item, 'SS', another #)
[2:18 PM] brian_skinner: seems like th store should throw an exception
[2:18 PM] brian_skinner: the store
[2:18 PM] aszs: yes
[2:19 PM] brian_skinner: the store should also throw an exception if you try to create a new item that has the same SSN as an existing item
[2:19 PM] aszs: that might only happen until save() though
[2:19 PM] brian_skinner: on save()?
[2:19 PM] aszs: the client doesn't know
[2:19 PM] brian_skinner: right
[2:19 PM] brian_skinner: bummer
[2:20 PM] aszs: anyways,
[2:20 PM] aszs: should we adjourn, maybe talk about open record a little?
[2:20 PM] brian_skinner: yup, that sounds good