On 2014-07-11 23:18, Mike Bayer wrote:
>
> On 7/11/14, 5:07 PM, Staszek wrote:
>> On 2014-02-01 00:09, Michael Bayer wrote:
>>> On Jan 31, 2014, at 5:24 PM, lars van gemerden <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> Hi, all
>>>>
>>>> I am running into these 2 errors and have run out of ideas what to do
>>>> about it (also because i don't what they mean); They seem to happen in
>>>> exactly the same circumstances.
>>>>
>>>> mapper, table, update)
>>>> File "build\bdist.win32\egg\sqlalchemy\orm\persistence.py", line
>>>> 514, in _emit_update_statements
>>>> (table.description, len(update), rows))
>>>> StaleDataError: UPDATE statement on table 'Company' expected to update
>>>> 1 row(s); 0 were matched.
>>> this means an object was meant to be UPDATEed via the ORM, however the
>>> row which is the target of the UPDATE is missing. Either the primary
>>> key of this row changed somehow, or the row was deleted, *or* the row is
>>> not visible to your transaction (this seems to be your case).
>> I am running into something very similar:
>>
>> StaleDataError: UPDATE statement on table 'buildings' expected to update
>> 1 row(s); 0 were matched.
>>
>> However this case is very simple, just a single row in a table, and it
>> looks to get selected just before the update (in the same transaction).
>> Nothing is being deleted.
>>
>> The update:
>>
>> UPDATE buildings SET glatitude=%s, glongitude=%s WHERE buildings.id = %s
>>
>> The columns:
>>
>> id = Column(BigInteger, autoincrement=True, primary_key=True)
>> glatitude = Column(Numeric(precision=11, scale=8))
>> glongitude = Column(Numeric(precision=11, scale=8))
>>
>> What's interesting is that the error occurs only if glatitude and
>> glongitude are being updated to the same values that are already in the
>> database (i.e.: no real update).
>> When the old values are NULL or otherwise different than the new values,
>> everything works fine!
>>
>> Is this a bug?
> It's unlikely to be a SQLAlchemy bug, but questions to be answered
> include: Can you produce a self-contained test case? Have you tried
> SQLAlchemy 0.9.6 rather than 0.9.1? Also what backend is this, MySQL?
> MySQL has had some bugs where the rowcount is not reported correctly.
Not really, no, yes.
The problem seems to have been with assignment of float values. It was
like this:
base.py:847: UPDATE buildings SET glatitude=%s, glongitude=%s WHERE
buildings.id = %s
base.py:849: (52.0210673, 20.2152834, 1)
It can't be seen here, but then I guess those float values were being
converted by SQLAlchemy to decimals like:
Decimal('52.021067299999998567727743647992610931396484375')
which was not equal to the value stored in the column because it has
lower precision.
However after converting those new values to Decimal *and* quantizing:
d = Decimal('0.00000001')
glat = Decimal.from_float(glat).quantize(d)
glon = Decimal.from_float(glon).quantize(d)
the new Decimals are equal to the old Decimals and I can see no UPDATE
in the log.
Not sure how it exactly works on SQLAlchemy side but perhaps it could
make sense to take the column precision into consideration when
comparing decimals on assignment/update.
--
http://people.eisenbits.com/~stf/
http://www.eisenbits.com/
OpenPGP: 80FC 1824 2EA4 9223 A986 DB4E 934E FEA0 F492 A63B
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
