On Wednesday 22 February 2006 09:27, Oleg Broytmann wrote:
> On Wed, Feb 22, 2006 at 01:21:58AM +0100, David Faure wrote:
> > +`createSQL`:
> > + SQL queries run after table creation. createSQL can be a string wit=
> > + single SQL command, a list of SQL commands, or a dictionary with ke=
> > + are dbNames and values that are either single SQL command string or=
> > + of SQL commands. This is usually for ALTER TABLE commands.
> > + ``%s``, if present, is substituted with the name of the table.
> Thank you!
> > +`lockRows`:
> > + A boolean (default False). If True, then any SELECT statement will=
> > + ``FOR UPDATE`` so that the corresponding rows are write-locked until
> > + the end of the current transaction.
> I think this should be an attribute or patameter of .select(), not
> sqlmeta. You don't want to write
> MyTable.sqlmeta.lockRows =3D True
> MyTable.sqlmeta.lockRows =3D False
> especially in a multitreaded application...
I wasn't thinking of toggling lockRows on and off, but rather as something =
would always be on in applications that use transactions.
The problem with modifying select() is that it's only one case where a SELE=
is being made. I see 4 calls to _SO_selectOne (plus one to the Alt version)=
=46or instance when creating an instance of the sqlobject-derived-class, wh=
calling sync() (not sure what that's for), and apparently also when accessi=
since values out of an instance, which can call loadvalue or getvalue.
How should we then control what happens there, if not by some kind of
object setting like sqlmeta.lockRows?
I think that sqlmeta.lockRows is the best way to make -all- selects lock ro=
independently of the operation and level of abstraction being used=20
(creating an instance, calling select() or accessing columns).
David Faure -- faure@..., dfaure@...
KDE/KOffice developer, Qt consultancy projects
Klar=E4lvdalens Datakonsult AB, Platform-independent software solutions