On Tue, 2006-12-12 at 00:33 +0300, Oleg Broytmann wrote:
> > or using a
> > liveness marker which is atomically set at the end of creation. Either
> > of these would work.
>
>Patches could be submitted to the SF tracker.
OK:
http://sourceforge.net/tracker/index.php?func=detail&aid=1614267&g
On Mon, Dec 11, 2006 at 04:16:23PM -0500, David Turner wrote:
> >Because accessing the DB during row creation when the "row" is actually
> > a set of rows exposes the inconsistent state of the DB, and SQLObject
> > certainly cannot prevent this.
>
> Sure it can -- using transactions in the way
On Mon, 2006-12-11 at 23:52 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 03:37:38PM -0500, David Turner wrote:
> > >Shouldn't it be considered a bug in the user program if it access the
> > > DB
> > > during row creation?
> >
> > I don't see why it should be.
>
>Because accessi
On Mon, Dec 11, 2006 at 03:37:38PM -0500, David Turner wrote:
> >Shouldn't it be considered a bug in the user program if it access the DB
> > during row creation?
>
> I don't see why it should be.
Because accessing the DB during row creation when the "row" is actually
a set of rows exposes
On Mon, 2006-12-11 at 23:02 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 02:57:03PM -0500, David Turner wrote:
> > This is not quite true, if I understand correctly. First, sqlobject
> > creates the base row, then (if necessary) it calls methods to get
> > default values for the derived
On Mon, Dec 11, 2006 at 02:57:03PM -0500, David Turner wrote:
> This is not quite true, if I understand correctly. First, sqlobject
> creates the base row, then (if necessary) it calls methods to get
> default values for the derived class, then it creates the derived row.
> So the user's program d
On Mon, 2006-12-11 at 22:53 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 02:47:05PM -0500, David Turner wrote:
> > There's a bit of a tricky thing about transactions: we need to make sure
> > that the calculation of default values for the derived row takes place
> > outside (but simultane
On Mon, Dec 11, 2006 at 02:47:05PM -0500, David Turner wrote:
> There's a bit of a tricky thing about transactions: we need to make sure
> that the calculation of default values for the derived row takes place
> outside (but simultaneous with) the transaction, because anything inside
> the transact
On Mon, 2006-12-11 at 22:24 +0300, Oleg Broytmann wrote:
> On Mon, Dec 11, 2006 at 02:17:20PM -0500, David Turner wrote:
> > 1. Wait to create the row in base until just before the row in derived
> > is to be created.
> >
> > 2. (maybe) use transactions.
>
>We cannot wait because we need an i
On Mon, Dec 11, 2006 at 02:17:20PM -0500, David Turner wrote:
> 1. Wait to create the row in base until just before the row in derived
> is to be created.
>
> 2. (maybe) use transactions.
We cannot wait because we need an id from the parent table to insert a
new row to the child table with the
Consider the following code:
from sqlobject import *
from sqlobject.inheritance import InheritableSQLObject
__connection__ = "sqlite:/:memory:"
def default_morx():
deriveds = list(Derived.select())
if deriveds.count():
return deriveds[0].morx
else:
return -1
class Ba
11 matches
Mail list logo
