[1:19 PM] brian_skinner: so, it's 1:20 -- no sign of chris yet -- should we go ahead without him?
[1:20 PM] slightlyoff: can we?
[1:20 PM] ttrenka: yeah, was about to ask the same q
[1:20 PM] slightlyoff: ttrenka: plotkit is PURDY
[1:20 PM] ttrenka: if you have ideas for visual improvements, now's the time
[1:21 PM] slightlyoff: ttrenka: uh, colors, some idea of scale (the interval numbers), and the interval markers in the background
[1:21 PM] ttrenka: ok
[1:21 PM] ttrenka: colors where?
[1:21 PM] brian_skinner: well, it would certainly be better to have him here -- but i'm not sure that we should block on it -- we're already months behind schedule on the data-store api stuff
[1:21 PM] slightlyoff: fair enough
[1:21 PM] brian_skinner: peller: any idea how to ping chris?
[1:21 PM] slightlyoff: ttrenka: the color scheme for plotkit is much nicer than our defaults
[1:22 PM] ttrenka: yeah, but that's easy to change.
[1:22 PM] ttrenka: right now you can specify the color of a series yourself
[1:22 PM] peller: brian_skinner: I'll go look for him... still don't have VPN on my Mac. Hang on
[1:22 PM] ttrenka: the demos don't
[1:22 PM] ttrenka: but I can definitely improve the plot area
[1:22 PM] slightlyoff: ttrenka: well, having a purdy defaults matters a LOT
[1:23 PM] ttrenka: the brown in the demos too are specified via CSS on the main widget div
[1:23 PM] ttrenka: it's not part of the actual widget.
[1:23 PM] ttrenka: (the overall background)
[1:23 PM] slightlyoff: ttrenka: oh, hrm, then purdy DEMOS matter a lot
[1:23 PM] ttrenka: ok
[1:23 PM] slightlyoff: 'cause that's what's gonna get copied
[1:23 PM] ttrenka: i'll come up with something today or tomorrow then
[1:23 PM] ttrenka: I thought the area demo was pretty :)
[1:24 PM] slightlyoff: ttrenka: yes, it is
[1:24 PM] ttrenka: but yes, I can change the color assignments a little and the plot area
[1:24 PM] brian_skinner: anybody have a chance to look over the proposed ReadStore? api?
[1:24 PM] brian_skinner: http://dojo.jot.com/dojo.data.api.ReadStore
[1:24 PM] ttrenka: not yet, unfortunately, going now
[1:24 PM] * slightlyoff goes
[1:25 PM] ttrenka: (http://archive.dojotoolkit.org/nightly/tests/widget/Chart/test_area.html, if you're interested brian)
[1:25 PM] brian_skinner: ttrenka: thanks, i'll go look
[1:25 PM] aszs: yes
[1:25 PM] aszs: its the same as the readstore on main api page, right?
[1:25 PM] slightlyoff: yeah, if that had background line markers, some interval numbers along the axes, and differen't color on the bg, it'd be awesome
[1:26 PM] |<-- peller has left freenode ()
[1:26 PM] ttrenka: slightlyoff: yeah, I'll play with it today.
[1:26 PM] brian_skinner: aszs: yes, the dojo.data.api page transcludes the dojo.data.api.ReadStore? page
[1:26 PM] aszs: ok
[1:27 PM] ttrenka: so brian--how is this any different from collections.Dictionary?
[1:27 PM] ttrenka: (just playing devil's advocate)
[1:27 PM] slightlyoff: brian_skinner: so does this store support any kind of query syntax?
[1:28 PM] brian_skinner: ttrenka: one second, let me answer slightlyoff first, since that's easier
[1:28 PM] brian_skinner: slightlyoff: yes
[1:28 PM] ttrenka: ok, np :)
[1:28 PM] brian_skinner: we've talked about two types of queries -- in-memory queries and server queries
[1:28 PM] slightlyoff: brian_skinner: which function takes it?
[1:28 PM] brian_skinner: this api just has server-queries
[1:28 PM] ttrenka: slightly: fetchArray
[1:28 PM] brian_skinner: right
[1:28 PM] slightlyoff: brian_skinner: but getValues is different?
[1:28 PM] aszs: wouldn't it better to return an iterator and not an array?
[1:28 PM] brian_skinner: i didn't try to address in-memory queries
[1:29 PM] slightlyoff: aszs: I think it might be
[1:29 PM] brian_skinner: aszs: there's a separate portion of the API that does return an iterator
[1:29 PM] aszs: where?
[1:29 PM] brian_skinner: but, i think for simple use cases, a simple array is convenient
[1:30 PM] ttrenka: aszs: you could use collections.Iterator on this array
[1:30 PM] aszs: well, you can get the array from the iterator
[1:30 PM] brian_skinner: my goal was to break the whole API up into little self-contained portions
[1:30 PM] aszs: using the iterator allows for deferred and asynchronous implementation
[1:30 PM] brian_skinner: a simple, minimalist data-store implementation can choose to implement only one or two portions of the API
[1:30 PM] slightlyoff: right, but refactoring to support iterator returns is gonna be harder later than it will be now
[1:30 PM] -->| peller (n=peller@209-6-218-233.c3-0.nwt-ubr2.sbo-nwt.ma.cable.rcn.com) has joined #dojo-meeting
[1:31 PM] brian_skinner: here's the full API page, which includes all the portions, including the iterator stuff:
[1:31 PM] brian_skinner: http://dojo.jot.com/dojo.data.api
[1:31 PM] ttrenka: thank you, I was just trying to find that
[1:31 PM] peller: brian_skinner: I pinged Chris, but he's logged in remotely and hasn't responded yet FYI
[1:31 PM] aszs: i don't see the need for both
[1:31 PM] brian_skinner: it has a fetchIterator() method that would take the same query syntax as the fetchArray() method
[1:32 PM] brian_skinner: peller: thanks!
[1:32 PM] aszs: the convence is minimal
[1:32 PM] ttrenka: brian, looking at dojo.data.api.AsyncReadStore?, which has some relevance here...
[1:33 PM] ttrenka: I know I wrote the iterator in Collections, but I think a forEach and a map mechanism in that iterator would be HUGE.
[1:33 PM] slightlyoff: ttrenka: you can add it = )
[1:33 PM] aszs: oops i'm wrong -- it thought the iterator interface had an toArray() method
[1:33 PM] brian_skinner: aszs: okay, if fetchArray() isn't popular, we could get rid of that and move fetchIterator() up into the most basic ReadStore? API
[1:33 PM] ttrenka: i can indeed
[1:33 PM] aszs: shouldn't it?
[1:34 PM] slightlyoff: aszs: dunno, should it?
[1:34 PM] slightlyoff: brian_skinner: I think that fetchArray() just gives makes it harder to think about the API as a whole
[1:34 PM] brian_skinner: aszs: we could add a toArray() method on the iterator
[1:34 PM] ttrenka: shouldn't that really be a part of the resultset though?
[1:34 PM] aszs: what's resultset?
[1:34 PM] ttrenka: the thing that is returned from fetch
[1:35 PM] aszs: how is a resultset difference from an iterator?
[1:35 PM] slightlyoff: that's what featchArray/fetchIterator does, right?
[1:35 PM] ttrenka: the wiki page has it as an array
[1:35 PM] ttrenka: right
[1:35 PM] aszs: i think widget should consume iterators as much as possible
[1:35 PM] ttrenka: but the difference is that an iterator iterates on the resultset
[1:35 PM] aszs: not resultsets
[1:35 PM] aszs: that makes them a lot more general
[1:35 PM] ttrenka: wait.
[1:35 PM] ttrenka: makes what a lot more general?
[1:36 PM] aszs: widgets
[1:36 PM] ttrenka: ok, you lost me
[1:37 PM] aszs: we could write widgets that use the dojo.data apis to display and modify data
[1:37 PM] ttrenka: ah, ok.
[1:37 PM] ttrenka: i would think you'd want the resultset and not an iterator for that
[1:37 PM] slightlyoff: ?
[1:37 PM] ttrenka: let the widget determine how it wants to iterate over a set
[1:37 PM] slightlyoff: I don't really see a difference
[1:37 PM] aszs: me neither
[1:37 PM] slightlyoff: ttrenka: why?
[1:37 PM] brian_skinner: ttrenka: how would a resultset differ from an iterator?
[1:37 PM] slightlyoff: ttrenka: what does that buy you?
[1:37 PM] ttrenka: a resultset could take a number of different forms
[1:38 PM] ttrenka: we could pass back an array
[1:38 PM] ttrenka: or a dictionary
[1:38 PM] ttrenka: or an xml nodelist
[1:38 PM] ttrenka: or whatever
[1:38 PM] aszs: is the resultset api described anywhere?
[1:38 PM] slightlyoff: uh, lets just say "you'll get one of these"
[1:38 PM] slightlyoff: I don't see much value in not just cutting down what can be returned
[1:38 PM] ttrenka: ...yeah, kind of wishing Chris was here now
[1:38 PM] brian_skinner: aszs: no -- nobody has posted a description of a resultset api
[1:38 PM] ttrenka: :(
[1:39 PM] brian_skinner: it's vapor-spec :-)
[1:39 PM] slightlyoff: haha
[1:39 PM] aszs: have considered subclasses of iterator interface such as a MutableIterator? or a DeferredIterator??
[1:39 PM] aszs: i think we are better off defining those than pushing that to the dojo.data apis
[1:40 PM] brian_skinner: aszs: the dojo.data.api.AsyncReadStore? write up includes some use of Deferred-style API
[1:40 PM] brian_skinner: http://dojo.jot.com/dojo.data.api
[1:41 PM] brian_skinner: the iterator object acts sort-of like a deferred
[1:41 PM] aszs: yes, i'm suggesting that would not be necessary if there was a DeferredIterator?
[1:41 PM] slightlyoff: aszs: not everyone is Twisted-clued
[1:42 PM] brian_skinner: aszs: right, i think we may both saying the same thing -- in the async use case we want the fetchIterator() method to return an interator that has deferred-style behavior
[1:42 PM] brian_skinner: right now dojo has no DeferredIterator?, so that's something we need to invent
[1:43 PM] slightlyoff: I'm for inventing DeferredIterator? if it'll simplify the dojo.data stuff
[1:43 PM] slightlyoff: or at least move more code out of it = )
[1:43 PM] brian_skinner: slightlyoff: that would be great
[1:43 PM] ttrenka: added forEach and map.
[1:43 PM] brian_skinner: ttrenka: where'd you add them?
[1:43 PM] aszs: ttrenka: ?
[1:44 PM] ttrenka: in the wiki
[1:44 PM] ttrenka: async read store
[1:44 PM] brian_skinner: thanks
[1:44 PM] ttrenka: np
[1:44 PM] slightlyoff: ttrenka: heh, I though you'd added them to dojo.collections.Iterator ;-)
[1:44 PM] aszs: ok, so basically that is DeferredIterator?
[1:44 PM] ttrenka: map has been there for a long time already
[1:44 PM] ttrenka: forEach has been added to selective collections
[1:45 PM] brian_skinner: aszs: yes, or at least it's an emerging spec for some sort of Deferred Iterator
[1:46 PM] aszs: so maybe fetchIterator needs an option flags or keyword parameter
[1:46 PM] brian_skinner: i tried to give some sense of what a DeferredIterator? might look like, but it seems like a hard problem, and I wasn't sure just what it needed to be able to do
[1:46 PM] brian_skinner: aszs: yup, maybe so -- what options?
[1:46 PM] ttrenka: yeah, that's an overall issue, I think
[1:47 PM] aszs: depends on the implementation, e.g. maxcount, async or not, etc.
[1:47 PM] brian_skinner: okay
[1:48 PM] aszs: so if there's a general purpose DeferredIterator? then there's no need for a separate data.api.AsyncReadStore?
[1:48 PM] brian_skinner: i was thinking it would be nice if people could write simple data store implementations without having to worry about async stuff -- like if you just want to make something like a read-only CSV store, or a JSON data simple-store
[1:48 PM] aszs: yes of course
[1:49 PM] aszs: the flag i was thinking about would be for user than didn't want to deal with async results
[1:50 PM] slightlyoff: aszs: not sure how it simplifies then
[1:50 PM] aszs: just like the parameter in xmlhttprequest.send()
[1:50 PM] brian_skinner: right, the data.api.AsyncReadStore? API only actually has one method, fetchIterator() -- everything else there is just examples of talking to the iterator itself
[1:50 PM] slightlyoff: ok
[1:50 PM] aszs: slightlyoff: not sure i follow?
[1:51 PM] slightlyoff: aszs: you're still in the business of presenting 2 "modes" to the developer
[1:52 PM] aszs: slightlyoff: yes, i don't see how to avoid that if we want to support async results
[1:52 PM] aszs: but still there's on less interface
[1:52 PM] slightlyoff: uh, deferred handles it by just immediately calling back
[1:53 PM] aszs: ko
[1:53 PM] aszs: oops
[1:53 PM] aszs: ok
[1:53 PM] brian_skinner: slightlyoff, aszs: do one of you (or both of you) feel like taking a stab at posting a spec and some examples for the DeferredIterator? API, as well as a spec and examples for how you call fetchIterator?
[1:54 PM] aszs: then the flag would a requirement... but do you think that some implementation would have reasons to choose sync or async?
[1:54 PM] ttrenka: in all honesty, shouldn't we just assume async?
[1:55 PM] aszs: oops again... i mean wouldn't be a requirement
[1:55 PM] slightlyoff: yes
[1:55 PM] slightlyoff: I'm all for assuming async
[1:55 PM] slightlyoff: sync is just a special case of async = )
[1:55 PM] aszs: me too
[1:55 PM] ttrenka: if it's synchronous then the callbacks will be fired immediately
[1:55 PM] ttrenka: right
[1:56 PM] slightlyoff: so yeah, one interface
[1:57 PM] slightlyoff: I think we're only going to help folks by providing different "slices" of the API if they can always work with the results the same way
[1:57 PM] ttrenka: to be honest, I'm not really sure what having a read store and a write store buys us either?
[1:57 PM] slightlyoff: ttrenka: can simplify the implementation for read-only things by not having to worry about the writing methods?
[1:57 PM] ttrenka: unless (brian) you're using this as interface definitions
[1:57 PM] aszs: ttrenka: yes, that why i proposing a MutableIterator?
[1:58 PM] ttrenka: k
[1:58 PM] brian_skinner: there are two things -- the iterface definitions and the data stores that implement those interfaces
[1:58 PM] slightlyoff: yep
[1:58 PM] brian_skinner: simple read-only data stores won't want to have to implement a write-api
[1:58 PM] brian_skinner: read-only is probably a very common use case
[1:58 PM] brian_skinner: with a much simpler api
[1:59 PM] ttrenka: ok. so everything on http://dojo.jot.com/WikiHome/dojo.data.api are basically interface definitions.
[1:59 PM] brian_skinner: yup
[1:59 PM] ttrenka: ok
[1:59 PM] ttrenka: I'm going to make that clear then
[1:59 PM] slightlyoff: yes
[1:59 PM] slightlyoff: = )
[1:59 PM] brian_skinner: yup, thanks ttrenka
[1:59 PM] ttrenka: ok, done
[2:00 PM] brian_skinner: i was thinking that it would be good to have actual source code in SVN just for the API definitions
[2:00 PM] brian_skinner: so that documentation would automatically get generated
[2:00 PM] brian_skinner: and because SVN is where people look for inof
[2:00 PM] brian_skinner: info
[2:01 PM] brian_skinner: but a data-store implementation would not have to actually dojo.require() any of the interface files
[2:01 PM] aszs: so is clear() equivalent to setValues with an empty array?
[2:02 PM] aszs: or removes the attribute entirely?
[2:03 PM] brian_skinner: aszs: i'm not sure -- that needs soime thought, the distinction between having an attribute with no values vs. not having the attribute
[2:03 PM] brian_skinner: maybe that's not a distinction worth making
[2:03 PM] brian_skinner: RDF doesn't make that distinction, does it?
[2:03 PM] aszs: if not then there should be a clear()
[2:03 PM] aszs: shouldn'
[2:03 PM] brian_skinner: we talked about that distinction in Chander once
[2:04 PM] aszs: i'm having trouble typing today ;)
[2:04 PM] brian_skinner: okay, so then yes, I think clear() is equivalent to setValues with an empty array
[2:04 PM] aszs: if it is i don't think we need a clear()
[2:04 PM] aszs: but RDF doesn't make that distinction
[2:05 PM] aszs: so does a dictionary a la javascript and python
[2:05 PM] aszs: oops
[2:05 PM] aszs: RDF does make that distinction
[2:05 PM] brian_skinner: really?
[2:05 PM] aszs: yes
[2:05 PM] brian_skinner: wanh
[2:05 PM] aszs: there no notion as undefined
[2:05 PM] aszs: or null
[2:06 PM] aszs: hmmm
[2:06 PM] slightlyoff: aszs: if it's just a wrapper for setValues([]), I don't see the harm = )
[2:06 PM] brian_skinner: having some convenience functions is convenient ;-)
[2:06 PM] brian_skinner: and may make for more readable code
[2:07 PM] aszs: slightlyoff: the expense is confusion and cognitive overhead vs. minimal convenivence imho
[2:07 PM] slightlyoff: aszs: not buying it here
[2:08 PM] ttrenka: neither am i
[2:08 PM] brian_skinner: how about we mark clear() as an open issue -- something we might want to remove from the API?
[2:08 PM] aszs: ok
[2:08 PM] slightlyoff: clear() is a pretty, um, clear semantic ;-)
[2:08 PM] ttrenka: i had a similar issue with the first version of FilteringTable, and ended up adding the clear method for clarity
[2:08 PM] brian_skinner: okay
[2:08 PM] ttrenka: (the issue wasn't me using it, it was others trying to)
[2:09 PM] aszs: ok,
[2:09 PM] aszs: so is setValues([]) eqiveant to set(attribute, undefined)?
[2:10 PM] brian_skinner: yes, i think so
[2:10 PM] brian_skinner: although, to be honest, i had never considered that someone might has undefined as a value for set()
[2:11 PM] brian_skinner: i had only thought about passing null
[2:11 PM] slightlyoff: I'm gonna have to run
[2:11 PM] aszs: so setValue(att, []); assert(typeof get(att) == 'undefined')
[2:11 PM] brian_skinner: slightlyoff: okay -- same time next week?
[2:12 PM] slightlyoff: yep
[2:12 PM] slightlyoff: that works for me
[2:12 PM] brian_skinner: slightlyoff: you feel like taking a stab at writing up a deferredIterator spec?
[2:12 PM] ttrenka: l8r
[2:12 PM] slightlyoff: brian_skinner: uh, sure, send me mail about it?
[2:12 PM] brian_skinner: slightlyoff: will do
[2:12 PM] slightlyoff: otherwise I'm garunteed to forget =
[2:12 PM] slightlyoff: thank you!
[2:13 PM] aszs: ok does getValues('non-existent-attribute') return []
[2:14 PM] brian_skinner: yes
[2:14 PM] brian_skinner: oh, wait
[2:14 PM] brian_skinner: no, i'm not sure
[2:15 PM] ttrenka: if it helps at all...
[2:15 PM] brian_skinner: i think maybe it should return null or throw an exception in that case
[2:15 PM] brian_skinner: i don't have a sense of what return value would be the most convenient for users
[2:15 PM] ttrenka: one of the standards I did with all of the collections was that if a method was supposed to return multiple values, it always returns an array--even if it's empty
[2:15 PM] ttrenka: whereas methods to get a single value would return null
[2:16 PM] brian_skinner: ttrenka: yes, that's what i had in mind with the get() and getValues() methods
[2:16 PM] ttrenka: yeah, it helps to be consistent
[2:16 PM] ttrenka: so then getValues() will return []
[2:16 PM] ttrenka: no matter what.
[2:17 PM] brian_skinner: but I think aszs is pointing out that if we do that, then we can't faithfully introspect on some notions in some data formats (like RDF)
[2:17 PM] aszs: i think there need to be a way to test for the existence of an attribute
[2:17 PM] |<-- slightlyoff has left freenode ()
[2:17 PM] brian_skinner: aszs: okay
[2:18 PM] aszs: checking for undefined doesn't see enough since the attribute could have that as its value
[2:18 PM] brian_skinner: we could add a hasAttribute() method
[2:18 PM] ttrenka: I would agree with the need for a test for an attribute for sure, but I don't think that should affect get
[2:18 PM] brian_skinner: ttrenka: okay
[2:18 PM] aszs: yes
[2:19 PM] brian_skinner: so hasAttribute() always returns a boolean, and getValues() always returns an array, and get() sometimes returns null?
[2:19 PM] aszs: and i would think clear(att); assert( hasAttribute(att) == false);
[2:19 PM] brian_skinner: aszs: +1
[2:19 PM] ttrenka: ok
[2:19 PM] ttrenka: oh jeez, I gotta run
[2:19 PM] aszs: get should return undefined
[2:19 PM] aszs: just like the wiki says now
[2:19 PM] brian_skinner: okay
[2:19 PM] aszs: it return null only if it was set to null
[2:20 PM] brian_skinner: yup
[2:20 PM] aszs: setValue(att, []); assert( hasAttribute(att) == false); ?
[2:20 PM] ttrenka: talk to you guys next week
[2:20 PM] aszs: bye
[2:20 PM] |<-- ttrenka has left freenode ()
[2:21 PM] brian_skinner: aszs: i'm not sure about that one -- what do you think is right?
[2:21 PM] aszs: i think so
[2:22 PM] aszs: supporting multiple values in RDF is tricky
[2:22 PM] aszs: since RDF doesn't support it
[2:22 PM] brian_skinner: :-)
[2:23 PM] aszs: how does ibm map undefined to their SQL datastore?
[2:24 PM] brian_skinner: i don't know
[2:24 PM] aszs: peller: do you know?
[2:24 PM] aszs: undefined in javascript is kind of lame
[2:24 PM] brian_skinner: it's been 15 years since i did stuff with SQL -- at the time there was a notion of null values, but not undefined
[2:24 PM] aszs: yes
[2:24 PM] peller: aszs: I'm really not a DB guy, sorry
[2:25 PM] aszs: undefined in javascript is lame introduce 4 valued logic!
[2:25 PM] aszs: python throw an exception where javascript returns undefined
[2:25 PM] aszs: i think that is better
[2:26 PM] aszs: maybe it should be an error to call "set(att, undefined)"
[2:26 PM] peller: aszs: I don't know that IBM does a lot with JS<>SQL. Most of the mappings are C or Java where you wouldn't have an undefined?
[2:26 PM] brian_skinner: well, we could change the data store API spec to require that conforming data store implementations never return undefined
[2:27 PM] brian_skinner: aszs: i'd be fine with saying that "set(att, undefined)" throws an exception
[2:27 PM] aszs: what does your JS SDO implementation do if undefined is set?
[2:28 PM] brian_skinner: aszs: what do you think about the whole notion of this modular API, with some data stores implementing portions of the API and some data stores implementing the whole API?
[2:28 PM] aszs: i'm all for that!
[2:28 PM] brian_skinner: :-)
[2:29 PM] brian_skinner: and what do you think about the breakdown as it appears now in http://dojo.jot.com/dojo.data.api ?
[2:30 PM] brian_skinner: some of the stuff near the bottom of the page is pretty speculative
[2:30 PM] aszs: look pretty good
[2:30 PM] brian_skinner: cool
[2:30 PM] aszs: not sure about TransactionalStore?
[2:31 PM] brian_skinner: then maybe we're pretty close to getting something that everybody might be game to sign off about
[2:31 PM] brian_skinner: at least for the first 5 or 6 parts of the API
[2:32 PM] brian_skinner: the Transactional stuff is important in OpenRecord -- but I think it could be implemented as a simple mixin that works with an simple ReadWrite? datastore
[2:32 PM] brian_skinner: with any simple ReadWrite? datastore
[2:32 PM] aszs: so
[2:33 PM] aszs: what does endTransaction() do
[2:33 PM] brian_skinner: it depends
[2:33 PM] aszs: how is it different from save() or rollback()
[2:33 PM] brian_skinner: let's say your code looks like this:
[2:34 PM] aszs: if we could just agree on ReadStore? and WriteStore? would that be enough?
[2:34 PM] aszs: for starters
[2:34 PM] brian_skinner: beginTrans(); store.set(foo, "bar", 1); beginTrans(); store.set(foo, "iggy", 1); endTrans(); endTrans();
[2:34 PM] brian_skinner: the first endTrans() does nothing
[2:35 PM] brian_skinner: the second endTrans() calls save()
[2:35 PM] brian_skinner: yes, if we can just agree on ReadStore? and WriteStore?, that would go a long way towards unblocking progress
[2:35 PM] aszs: who do you know implements nested transactions?
[2:35 PM] brian_skinner: ?
[2:36 PM] brian_skinner: um, I'm not sure
[2:36 PM] aszs: JDBC doesn't support that
[2:36 PM] aszs: it uses savepoint instead
[2:36 PM] aszs: because no SQL database support nested transactions
[2:36 PM] brian_skinner: I've definitely seen it somewhere
[2:36 PM] aszs: instead they support checkpoints or savepoints
[2:36 PM] aszs: yes they exist
[2:37 PM] aszs: but rarely
[2:37 PM] brian_skinner: i don't know how to write modular code without them
[2:37 PM] brian_skinner: class A has a method foo, and class B has a method bar, and foo calls bar
[2:37 PM] brian_skinner: bar should be written without knowledge of foo
[2:38 PM] brian_skinner: bar needs to do a beginTrans(); edit; endTrans();
[2:38 PM] brian_skinner: foo needs to do a beginTrans(); edit; B.bar(); edit; endTrans();
[2:38 PM] aszs: yes, i understand the attraction
[2:38 PM] brian_skinner: is there a better alternative?
[2:39 PM] brian_skinner: or just a different alternative?
[2:39 PM] aszs: but millions of lines of Java database code doesn't do that
[2:39 PM] brian_skinner: how do they do it?
[2:39 PM] aszs: JDBC doesn't have a begintransaction
[2:39 PM] aszs: aside, another problem is supporting autocommit
[2:39 PM] brian_skinner: do they get the same effect with checkpoints or savepoints?
[2:39 PM] aszs: yes and no
[2:40 PM] aszs: so JDBC just has commit() and rollback()
[2:40 PM] aszs: and an autocommit attribute
[2:41 PM] brian_skinner: an autocommit attribute?
[2:41 PM] aszs: so bar would have create a savepoint if what to be able to undo the work it did
[2:41 PM] aszs: yes
[2:41 PM] aszs: autocommit = true
[2:41 PM] aszs: means commit() and rollback() are no ops
[2:42 PM] aszs: every modification is commited immediately
[2:42 PM] aszs: if a database didn't support transactions autocommit is always true
[2:42 PM] brian_skinner: okay
[2:43 PM] aszs: nested transaction are relally hard to implement robustly and basically don't exist in the SQL world
[2:44 PM] brian_skinner: so if we want nested transactions for openrecord, we could have that code in the OpenRecord client code, rather than in the datastore implementation
[2:44 PM] aszs: yes...
[2:45 PM] aszs: and you might find it isn't necessary... what's wrong with rolling back the whole transaction if something goes wrong?
[2:46 PM] aszs: this kind of goes back to the discussion about having a save button
[2:46 PM] brian_skinner: i think you do want to roll back the whole transaction -- the nested transaction thing just makes it easy to mark where the whole transaction begins and ends
[2:47 PM] brian_skinner: if foo() calls bar(), then the whole transaction starts and ends in foo()
[2:47 PM] brian_skinner: if you call bar() directly, then the whole transaction starts and ends in bar()
[2:47 PM] brian_skinner: if foo() calls bar(), the begin and end calls in bar() become no-ops
[2:47 PM] aszs: in most database apis there is no begintransaction()
[2:48 PM] aszs: an new transaction starts immediate after commit() or rollback() is called
[2:48 PM] aszs: so you don't have to worry about begintransaction nesting
[2:49 PM] brian_skinner: right, but if foo() calls bar(), it's important that bar() not have a commit() statement that actually does anything
[2:49 PM] brian_skinner: you don't want to commit until foo is done
[2:49 PM] aszs: yes
[2:50 PM] aszs: yes bar() would never call commit()
[2:50 PM] brian_skinner: in the sort of nested transactions i'm talking about, this is all just done in client-side code -- there's no actual server database feature involved
[2:50 PM] aszs: yes
[2:50 PM] brian_skinner: the begin and end pairs just help the client code figure out when to actually commt
[2:50 PM] brian_skinner: commit()
[2:51 PM] brian_skinner: seems simple/harmless
[2:52 PM] brian_skinner: ...
[2:52 PM] aszs: so did i convince you that it should not be part of the data store api?
[2:52 PM] aszs: instead just add a rollback() alongside save() in the writestore
[2:52 PM] brian_skinner: i'm happy to leave it out of the datastore api
[2:52 PM] aszs: and implement the begin/end in the client?
[2:52 PM] aszs: cool
[2:53 PM] brian_skinner: i don't see the harm in offering it as an optional mixin, but we can talk about that later
[2:53 PM] brian_skinner: seems like the real thing to worry about now is the DeferredIterator? api, and the fetchIterator() api
[2:53 PM] brian_skinner: do you feel like taking a stab at those?
[2:53 PM] aszs: ok, but in that case rollback() still needs to be moved to WriteStore?()
[2:54 PM] aszs: ok
[2:54 PM] brian_skinner: aszs: okay, i'll move rollback() to WriteStore?()
[2:55 PM] brian_skinner: is rollback() the right name for that?
[2:55 PM] aszs: so i don't envision the RDF datastore implementing the Metamodel stuff
[2:55 PM] aszs: yes
[2:55 PM] brian_skinner: the pairing of save() and rollback() seems weird
[2:55 PM] brian_skinner: commit() and rollback() seem natural
[2:55 PM] brian_skinner: or save() and ___ ?
[2:55 PM] aszs: yes i agree
[2:55 PM] aszs: forget()?
[2:55 PM] aszs: discard()
[2:55 PM] brian_skinner: :-)
[2:56 PM] brian_skinner: cancel()
[2:56 PM] aszs: i like commit/rollback() if it ok to rename save()
[2:56 PM] brian_skinner: we can rename save()
[2:56 PM] aszs: oh yeah cancel() the obvious one
[2:57 PM] aszs: but maybe less precise in meaning
[2:57 PM] brian_skinner: okay, i'll use commit/rollback for now, and i'll put in a note about possible other names
[2:57 PM] aszs: sounds good
[2:57 PM] aszs: should we adjurn?
[2:57 PM] aszs: adjourn?
[2:57 PM] brian_skinner: more stuff to talk about today, or shoud adjourn?
[2:58 PM] brian_skinner: jinx
[2:58 PM] aszs: i concur
[2:58 PM] brian_skinner: next tuesday at 1:00?
[2:58 PM] aszs: ok
[2:58 PM] aszs: works for me
[2:58 PM] brian_skinner: cool -- thanks!
[2:58 PM] brian_skinner: bye peller!
[2:58 PM] aszs: i thinking we're making progress
[2:58 PM] aszs: ...
[2:58 PM] aszs: bye
[2:59 PM] brian_skinner: yup
[2:59 PM] brian_skinner: bye
[2:59 PM] <--| aszs has left #dojo-meeting