Re: API policy

[Philip Martin <ph...@wandisco.com>]

Greg Stein <gs...@gmail.com> writes:

> I recognize we need to grow the scope of transactions for speed purposes,
> but let's do it in a way based on semantics rather than implementation. For
> example: to speed checkout, we could have an API to add a complete directory
> of nodes, rather than an API to start/end a txn across those single
> additions.

That doesn't seem to fit with our current editor.  When we want to add a
directory we don't know the nodes.  If we delay adding the directory
until the nodes are known we would have to store the entire checkout
somewhere else.

-- 
Philip

Re: API policy

[Greg Stein <gs...@gmail.com>]

On Mar 28, 2011 8:23 AM, "Philip Martin" <ph...@wandisco.com> wrote:
>
> Greg Stein <gs...@gmail.com> writes:
>
> > I recognize we need to grow the scope of transactions for speed
purposes,
> > but let's do it in a way based on semantics rather than implementation.
For
> > example: to speed checkout, we could have an API to add a complete
directory
> > of nodes, rather than an API to start/end a txn across those single
> > additions.
>
> That doesn't seem to fit with our current editor.  When we want to add a
> directory we don't know the nodes.  If we delay adding the directory
> until the nodes are known we would have to store the entire checkout
> somewhere else.

I'm well aware of the implications. I'm just trying to say: let's try to
avoid poisoning our entire WC library with SQL transaction concepts, which
should be restricted to just the internals of wc_db.

Cheers,
-g