Hi,
I'm trying to get my head around the attached scenario - unfortunately the
documentation and aunt Google weren't too helpful :/
My expectation (up until now) was that an object that I mark as deleted
would become useless for the application, similar to being detached after
closing a
that's definitely a bug and am looking into it.
if you *dont* delete the object, then it shows up as detached and all that :)
On Feb 1, 2013, at 3:37 AM, Christian Theune wrote:
Hi,
I'm trying to get my head around the attached scenario - unfortunately the
documentation and aunt Google
On Jan 31, 2013, at 12:47 PM, Jorge Flávio Aquino da Costa wrote:
yeah that's where the MSSQL dialect is doing things that aren't going to work
with QODBC. I don't have a quick fix for this for you, it would require
creating a new dialect that doesn't perform these particular startup
OK, had to think a bit for how this should be done.
What i've come up with is at http://www.sqlalchemy.org/trac/ticket/2658. The
good news is that you should be able to work around your issue right now if you
just look at the state.deleted flag, which in the patch I'm adding a new helper
On Fri, Feb 1, 2013 at 12:55 PM, Michael Bayer mike...@zzzcomputing.comwrote:
On Jan 31, 2013, at 12:47 PM, Jorge Flávio Aquino da Costa wrote:
yeah that's where the MSSQL dialect is doing things that aren't going to
work with QODBC. I don't have a quick fix for this for you, it would
On Feb 1, 2013, at 12:40 PM, Jorge Flávio Costa wrote:
At the moment, I´ll keep improving the dialect to remove those errors and
warning messages so it could be used by others interested in Caché
development. Any tips regarding where I should start? What´s the least common
denominator
When I delete[*1] a mapped object (a Title()) that is on the many side
of a 1:m relationship (in sqlalchemy 0.8.0b2, Python 3.3), I get the
following error when I do a session.commit():
[...earlier part of traceback elided...]
File
No suggestions?
On Wednesday, January 30, 2013 1:31:33 PM UTC-7, ru...@yahoo.com wrote:
[...]
How can I determine what [attributes] has been changed, even after
a flush? (Or should I disable autoflushing?)
How to revert some changes (but not all; for that I
would just do a rollback,
I am working from Copeland's Sqlalchemy book and he describes
giving an echo_uow argument to Session() to enable unit-of-
work messages. But perhaps the book refers to an old version
of SA because I can find no documentation on that parameter
(and both Session and sessionmaker reject it as
On Feb 1, 2013, at 1:02 PM, ru...@yahoo.com wrote:
When I delete[*1] a mapped object (a Title()) that is on the many side
of a 1:m relationship (in sqlalchemy 0.8.0b2, Python 3.3), I get the
following error when I do a session.commit():
[...earlier part of traceback elided...]
File
On Feb 1, 2013, at 1:06 PM, ru...@yahoo.com wrote:
I am working from Copeland's Sqlalchemy book
please do not use this book. It is many years out of date, and was in fact
already outdated the day it was published as we were up to 0.4 by then.
The official documentation for SQLAlchemy is the
attribute history features are available via get_history():
http://docs.sqlalchemy.org/en/rel_0_8/orm/session.html?highlight=get_history#sqlalchemy.orm.attributes.get_history
However this history is only active until the next flush. I doubt it's
appropriate as a substitute for implementing a
i forgot to add that this all comes from my irrational fear of Little
Bobby Tables ( http://xkcd.com/327/ )
--
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
13 matches
Mail list logo
