Hi!
In production server, in our product we use postgresql as db engine,
than supports schema name as sqlalchmy's feature. But we have unit-
tests, that must passed without postgresql server.
In code we use schema names and foreign keys. There are a lot of
topics with sqlite does not support
On Nov 11, 2010, at 7:50 PM, Sergey V. wrote:
relationship() expects a class or a mapper instance, not a string. I
got this error:
ArgumentError: relationship 'available_deals' expects a class or a
mapper argument (received: type 'str')
Hmm... I'm not sure what I'm doing wrong but
Hello everyone.
I was wondering if it's possible to inherit a custom collection to
create another custom collection.
A few days ago I was trying to use my own class as a custom_collection
(http://groups.google.com/group/sqlalchemy/msg/ba1c64c3d227f586).
Thanks to Michael Bayer I
On Nov 12, 2010, at 9:37 AM, Gennady Kovalev wrote:
Hi!
In production server, in our product we use postgresql as db engine,
than supports schema name as sqlalchmy's feature. But we have unit-
tests, that must passed without postgresql server.
In code we use schema names and foreign
I implemented that fix, as well as an additional change so that the
REFERENCES clause is omitted entirely only if the two schemas of the tables
are different, that is as of 8cc53b0afb99 .
It is a good solution. Thank you.
--
You received this message because you are subscribed to the
On Nov 12, 6:42 am, Michael Bayer mike...@zzzcomputing.com wrote:
But generally usage of mapper() wasn't intended to provide any tricks
around import issues. You can always use mapper.add_property(...) to attach
things as needed, and class_mapper(Class) to call up any mapper anywhere.
You're welcome, and I hope that works for you. I went through the
same process a few years ago when picking up SqlAlchemy... the backref
facility is so cool that it's easy to forget that it's optional and
that most relationship backrefs /could/ be handled as just another
relationship on the
Yeah... I'm pretty newbie myself with sqlalchemy, so when I discovered
that I could specify primary joins, secondary... and all that juicy
stuff in the backref I got so into writing it from A -- to -- B
that I forgot that it can be done B --from-- A
:) Thanks again!
2010/11/12 Eric Ongerth
Hi,
I just want to check on something. Let's say I've got a script that's
populating a database and will commit the transaction at the end. It looks for
a particular object (let's call it A), and if NoResultFound it creates a new
object and does a session.add(A).
What if in a later iteration
On Nov 12, 2010, at 7:32 PM, thatsanicehatyouh...@mac.com wrote:
Hi,
I just want to check on something. Let's say I've got a script that's
populating a database and will commit the transaction at the end. It looks
for a particular object (let's call it A), and if NoResultFound it creates
Thanks for the quick reply!
On Nov 12, 2010, at 7:41 PM, Michael Bayer wrote:
mm, right there that's not the default behavior. If you did an add(A), the
next query() you do will autoflush. A is now in the database within the
scope of the current transaction, so query() will find it.
Yes,
On Nov 12, 2010, at 7:49 PM, thatsanicehatyouh...@mac.com wrote:
Thanks for the quick reply!
On Nov 12, 2010, at 7:41 PM, Michael Bayer wrote:
mm, right there that's not the default behavior. If you did an add(A), the
next query() you do will autoflush. A is now in the database within
Just a heads-up:
I was experimenting with various cascade options on mappers and came
across the following warning:
SAWarning: The 'delete-orphan' cascade option requires 'delete'.
This will raise an error in 0.6.
But I'm running 0.6.5. Maybe this warning message just never got
updated since
13 matches
Mail list logo
