I have a model with an ID column set as the primary key, though i'd like to be
able to identify records by 3 other columns.
For this situation, I've added a classmethod that will fetch the record if
found or a new record if not.
The problem i'm having is that every once in a while, I get
On Tue, Aug 27, 2013 at 1:40 PM, herzaso herz...@gmail.com wrote:
I have a model with an ID column set as the primary key, though i'd like to
be able to identify records by 3 other columns.
For this situation, I've added a classmethod that will fetch the record if
found or a new record if not.
On Mon, Aug 26, 2013 at 11:17 PM, Mohsen Pahlevanzadeh
m.pahlevanza...@gmail.com wrote:
Dear all,
i have the following delete record function:
def deleteRecord(self,tableObj):
self.session.delete(tableObj);
self.session.commit();
When i call the abobe function,
Hi Simon,
Thanks for the fast reply.
I tried adding session.add(item) and session.flush() in the else clause in
the past but that didn't solve my problem.
I didn't however remove the merge, do you think that might be the problem?
Regarding the flush, this code is part of an API server where a
On Tue, Aug 27, 2013 at 2:31 PM, herzaso herz...@gmail.com wrote:
On Tuesday, August 27, 2013 3:55:50 PM UTC+3, Simon King wrote:
On Tue, Aug 27, 2013 at 1:40 PM, herzaso her...@gmail.com wrote:
I have a model with an ID column set as the primary key, though i'd like
to
be able to
I'm running a Tornado server without redundancy (only one process, requests
can arrive at the same time but will be handled one at a time)
I do agree that for large volumes, catching the IntegrityError would be
better, but currently I am handling a single request at a time and I want
to fix
the word occasional is very meaningful. It usually suggests race conditions.
Then with the word tornado, the baysean filters are strongly leaning
towards race condition at that point :).
if an error is occurring only under volume then you have to revisit where race
conditions can occur.
Suppose we are looking at a race condition, do you also think this should
be handled by catching the IntegrityError?
If so, what should I do? only flush and do the operation again?
On Tuesday, August 27, 2013 5:42:23 PM UTC+3, Michael Bayer wrote:
the word occasional is very meaningful. It
I'm not a fan of catching integrity errors, i prefer to try to make sure they
aren't going to happen, or if they are, they aren't a normal occurrence and the
system is such that the particular operation can just fail (of course it
depends on what it is). A problem with catching the
Thanks Michael,
I will try that and let you know if it solved my issue.
BTW: Is there a lock mechanism for such conditions?
Thanks,
Ofir
On Tuesday, August 27, 2013 6:40:03 PM UTC+3, Michael Bayer wrote:
I'm not a fan of catching integrity errors, i prefer to try to make sure
they aren't
when you have concurrent transactions going on, the database should be
responsible for dealing with whatever locking is required. the optimistic
approach i have outlined doesn't require any locking, but you could also do
this using an explicit table lock - the syntax and availability of
My ddd object :
ddd = SellersTable(dict([('name_type',1) ]))
dbObj.deleteRecord(ddd);
SellersTable is a class table that contains __tablename__ and fileds name.
I pass a dictionary that consist of my field and its value.
I chekced, it stored in DB.
On Tuesday, August 27, 2013 2:47:46 AM
session.delete() only works with instances which are already part of that
session. Here's an example:
ddd = session.query(SellersTable).filter_by(name_type=1).one()
session.delete(ddd)
This will SELECT the row from the database first, then perform the DELETE using
the object's primary key.
13 matches
Mail list logo
