Hello!
On Thu, Mar 09, 2006 at 02:01:58PM +0100, David Faure wrote:
> OK, I have reworked the support for "select for update" so that it now looks
> like
> obj.select(forUpdate = True)
>
> Patch and testcase attached.
I have applied the patch without the test (the test still needs some
wor
On Tue, Mar 21, 2006 at 10:46:25AM +0100, David Faure wrote:
> On Tuesday 21 March 2006 10:24, Oleg Broytmann wrote:
> > > for i in xrange(100):
> > > print i
> > >
> > > try:
> > > agg = Aggregates.select(connection = t, forUpdate =
> > > True).getOne()
> > >
On Tuesday 21 March 2006 10:24, Oleg Broytmann wrote:
> > for i in xrange(100):
> > print i
> >
> > try:
> > agg = Aggregates.select(connection = t, forUpdate =
> > True).getOne()
> > except:
> > agg = Aggregates(total = 0, connection = t)
>
On Tue, Mar 14, 2006 at 06:50:14PM +0300, Oleg Broytmann wrote:
> On Thu, Mar 09, 2006 at 02:01:58PM +0100, David Faure wrote:
> > OK, I have reworked the support for "select for update" so that it now
> > looks like
> > obj.select(forUpdate = True)
> >
> > Patch and testcase attached.
>
>
On Thu, Mar 09, 2006 at 02:01:58PM +0100, David Faure wrote:
> OK, I have reworked the support for "select for update" so that it now looks
> like
> obj.select(forUpdate = True)
>
> Patch and testcase attached.
You have forgotten to patch (of forgot to include diff) sresults.py. And
your te
On Saturday 25 February 2006 11:27, you wrote:
> I think FOR UPDATE would be a good addition. I would expect it to be a
> parameter passed through to select. Even if people decide to go with a flag
> in the table definition, I think the parameter to select is still required
> to override the flag f
On Wed, Mar 08, 2006 at 03:06:25PM +0100, David Faure wrote:
> Hmm, the last line shouldn't have been added, since the support for '%s'
> hasn't been committed.
>
> --- docs/SQLObject.txt (revision 1634)
> +++ docs/SQLObject.txt (working copy)
> @@ -739,7 +739,6 @@ values are:
> single SQL
On Sunday 26 February 2006 16:46, 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 with a
> > + single SQL command, a list of SQL commands, or a dictionary with keys
> >
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 with a
> + single SQL command, a list of SQL commands, or a dictionary with keys that
> + are dbNames and values that are either single SQL command
David Faure wrote:
> And given that the Aggregates table will obviously always be used this way
> (updating a total), being able to set lockRows=true once and for all in the
> definition of that table makes sense to me; more than having to remember to
> pass "lock the rows" in each and every opera
On Wednesday 22 February 2006 14:51, Oleg Broytmann wrote:
> On Wed, Feb 22, 2006 at 02:48:42PM +0100, David Faure wrote:
> > >Why do you want to lock the row with cacheValues=False?
> >
> > Because another process might be accessing the same table row at the same
> > time.
>
>I do under
On Wed, Feb 22, 2006 at 02:48:42PM +0100, David Faure wrote:
> >Why do you want to lock the row with cacheValues=False?
>
> Because another process might be accessing the same table row at the same
> time.
I do understand what locking is. I do not understand locking with
cacheValues=False
On Wednesday 22 February 2006 14:40, Oleg Broytmann wrote:
> On Wed, Feb 22, 2006 at 02:34:59PM +0100, David Faure wrote:
> > >class sqlmeta:
> > > cacheValues = False
> > >
> > >Now EVERY access to an attribute causes SELECT or UPDATE.
> >
> > OK. Now if I want those SELECTS to loc
On Wed, Feb 22, 2006 at 02:34:59PM +0100, David Faure wrote:
> >class sqlmeta:
> > cacheValues = False
> >
> >Now EVERY access to an attribute causes SELECT or UPDATE.
>
> OK. Now if I want those SELECTS to lock the rows, how would I do that, if not
> with an sqlmeta boolean?
W
On Wednesday 22 February 2006 14:28, Oleg Broytmann wrote:
> On Wed, Feb 22, 2006 at 02:21:06PM +0100, David Faure wrote:
> > Could you help me a bit so that I can do the right thing then?
> > What's the idea behind loadvalue and getvalue issueing a SELECT statement?
> > I thought the select was do
On Wed, Feb 22, 2006 at 02:21:06PM +0100, David Faure wrote:
> Could you help me a bit so that I can do the right thing then?
> What's the idea behind loadvalue and getvalue issueing a SELECT statement?
> I thought the select was done by MyObject.select(), so why is select done
> (again? instead?)
On Wednesday 22 February 2006 14:01, Oleg Broytmann wrote:
> On Wed, Feb 22, 2006 at 01:26:49PM +0100, David Faure wrote:
> > I think that sqlmeta.lockRows is the best way to make -all- selects lock
> > rows,
>
>I dont think there is a general need to *always* lock rows for a table.
Well, my
On Wed, Feb 22, 2006 at 01:26:49PM +0100, David Faure wrote:
> I think that sqlmeta.lockRows is the best way to make -all- selects lock rows,
I dont think there is a general need to *always* lock rows for a table.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PRO
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 with a
> > + single SQL command, a list of SQL commands, or a dictionary with keys
>
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 with a
> + single SQL command, a list of SQL commands, or a dictionary with keys that
> + are dbNames and values that are either single SQL command
Attached is a patch that makes SELECT statement "FOR UPDATE" so that the
rows are locked within the current transaction. This is enabled by
sqlmeta.lockRows=True.
As a bonus here's the documentation update, including the missing docu for
createSQL:
--- SQLObject.txt (revision 1598)
+++ S
21 matches
Mail list logo
