Re: [sqlalchemy] Backref confusion
Thank you! That is exactly the function I needed. On Tuesday, November 13, 2012 9:16:47 PM UTC-8, Michael Bayer wrote: > > > On Nov 13, 2012, at 11:03 PM, Bobby Impollonia wrote: > > I have constructed a sample program consisting of two mapped classes > (using sqlalchemy.ext.declarative) that have a relationship/ backref > between them. At runtime the program does the following: > 1) Print whether the parent class has an attribute for its relationship to > the child (declared as the backref) > 2) Construct a child object > 3) Repeat step 1 > > The result (with SQLA 0.7.9) is that it prints 'False' during step 1 and > then 'True' during step 3. I would expect True to be printed both times. > > Here is the full source of the program: > https://gist.github.com/4070161 > > Why does the property not exist when the first print statement executes? > > > "addresses" is generated on the Person class when the mappers enter the > "configuration" step, which is an automatically invoked process which > occurs when a mapping is first used. this process is deferred until a > point at which it's safe to assume all mappings are present, so that > relationship() directives, which refer to other mappings, can proceed to > reconcile the mappings they point to - otherwise by definition one of the > mappings/classes (if using declarative) doesn't exist yet for > relationship/backref. > > the process can be manually invoked via configure_mappers(): > > if __name__ == '__main__': > from sqlalchemy.orm import configure_mappers > configure_mappers() > print hasattr(Person, 'addresses') > Address() > print hasattr(Person, 'addresses') > > > > > Thanks for any guidance. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sqlalchemy/-/SRZzsLt7qb0J. > To post to this group, send email to sqlal...@googlegroups.com > . > To unsubscribe from this group, send email to > sqlalchemy+...@googlegroups.com . > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/-lPqaGoaWcYJ. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] (SQLite) "Outside" auto-locking based on SQLAlchemy Events
On Nov 12, 2012, at 9:37 PM, Michael Bayer wrote:
>
> On Nov 12, 2012, at 5:33 PM, Torsten Landschoff wrote:
>
>>
>> BTW, I found one offender that breaks running database upgrades with my
>> locking schemes:
>>
>> from sqlalchemy import *
>> from sqlalchemy.pool import *
>>
>> engine = create_engine("sqlite:home/torsten/some.db",
>> poolclass=AssertionPool)
>> conn = engine.connect()
>> metadata = MetaData(conn, reflect=True)
>>
>> This results in the following backtrace here:
>>
>> raise AssertionError("connection is already checked out" + suffix)
>> AssertionError: connection is already checked out at:
>> File "demo.py", line 5, in
>> conn = engine.connect()
>>
>> I would have expected it to reflect using the connection passed to the
>> MetaData constructor.
>
> if so then that's a bug, added http://www.sqlalchemy.org/trac/ticket/2604 to
> take a look at that.
I've no idea how that silly API got in there, but seems a bit late to remove
it. I'm going to deprecate it though, for now use this form:
m = MetaData()
m.reflect(conn)
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlalchemy@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] with_polymorphic query and parent attribute filtering
On Nov 13, 2012, at 3:34 AM, tonthon wrote:
> Hi,
>
> I'm using polymorphism for some of my models and I'm wondering how I
> should use the with_polymorphic query method.
>
> Consider the following:
> """
> class A(Base):
> type_ = Column(Integer, nullable=False)
> arg = Column(String(20))
> __mapper_args__ = {'polymorphic_on': type_, 'polymorphic_identity': 0}
>
> class B(A):
>__mapper_args__ = {'polymorphic_identity': 1}
>
> class C(A):
>__mapper_args__ = {'polymorphic_identity': 2}
>
> class D(A):
>__mapper_args__ = {'polymorphic_identity': 3}
> """
>
> When I query :
>
> """
> session.query(A).with_polymorphic([B,C]).filter(A.arg == 'test')
> """
>
> I get D elements in my result.
> I've tried :
>
> """
> session.query(A).with_polymorphic([B,C]).filter(or_(B.arg=='test',
> C.arg=='test'))
> """
>
> But it doesn't work neither.
>
> Could somebody explain me what I did wrong and how I should do ?
with_polymorphic() is generally only useful with joined table inheritance (note
this is single table inheritance), and is used to add those subclass tables to
the Query so that you can filter() on their criterion, as well as to allow more
columns to be pulled in via a single query rather than needing to invoke
additional queries for subclass tables. It does not indicate a subset of
subclasses to be included.
If you want to load A's of type B, C, but not D, you'd need to do this manually
via the discriminator - since B, C and D are all As you normally will get back
all three as the rows determine.
session.query(A).filter(A.type_.in(0, 1, 2))
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] Backref confusion
On Nov 13, 2012, at 11:03 PM, Bobby Impollonia wrote: > I have constructed a sample program consisting of two mapped classes (using > sqlalchemy.ext.declarative) that have a relationship/ backref between them. > At runtime the program does the following: > 1) Print whether the parent class has an attribute for its relationship to > the child (declared as the backref) > 2) Construct a child object > 3) Repeat step 1 > > The result (with SQLA 0.7.9) is that it prints 'False' during step 1 and then > 'True' during step 3. I would expect True to be printed both times. > > Here is the full source of the program: > https://gist.github.com/4070161 > > Why does the property not exist when the first print statement executes? "addresses" is generated on the Person class when the mappers enter the "configuration" step, which is an automatically invoked process which occurs when a mapping is first used. this process is deferred until a point at which it's safe to assume all mappings are present, so that relationship() directives, which refer to other mappings, can proceed to reconcile the mappings they point to - otherwise by definition one of the mappings/classes (if using declarative) doesn't exist yet for relationship/backref. the process can be manually invoked via configure_mappers(): if __name__ == '__main__': from sqlalchemy.orm import configure_mappers configure_mappers() print hasattr(Person, 'addresses') Address() print hasattr(Person, 'addresses') > > Thanks for any guidance. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sqlalchemy/-/SRZzsLt7qb0J. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] automatically casting a class to a subclass via polymorphic discriminator?
On Nov 13, 2012, at 7:59 PM, Gerald Thibault wrote:
> I have a base class which has two subclasses specified via a polymorphic
> discriminator, and I'm wondering how to set things up so the returned results
> are instances of the subclass, when I create an instance of the base class
> and assign the relevant value to the discriminator column. Here's my example
> code:
that's not how it usually works. You'd create instances of the subclasses, and
leave the discriminator column alone; SQLAlchemy assigns that.
>
> test1 = Test(type='one', name='a test')
> session.add(test1)
> print test1
>
> This returns an instance of Test, not Test1, despite the discriminator
> indicating that it should be cast as Test1.
OK here, you've said "test = Test()". That is now the Python version of the
class, SQLAlchemy has nothing to do with changing __class__ on your Test object
or anything like that. That object is going to stay just like it is, except
for it getting a new primary key value. SQLAlchemy's job here is to persist
your row in the database and return it back for you later. Here, the session
hasn't even flushed any data, and you can see in your echo there's not any
INSERT. If you were to allow the row to go out to the database and come back,
you'd see your class:
test1 = Test(type='one', name='a test')
session.add(test1)
session.commit() # flush + commit transaction
session.close() # expunge the "Test()" object totally so we get a new one
back
print session.query(Test).one()
above, it's important that "test1" is removed from the Session totally, so that
when we query again for that row, the Test object isn't returned; otherwise, it
still points to that row.
However, the way it's supposed to work is, just use the classes as designed
(note also, we use Session, or sessionmaker() - not create_session() which is a
legacy function used for internal testing - see
http://docs.sqlalchemy.org/en/rel_0_7/orm/session.html for recommended usage
patterns):
from sqlalchemy.orm import Session
session = Session(e)
test1 = TestOne(name='a test')
session.add(test1)
print session.query(Test).one() # autoflushes, then gets our TestOne back
> Also, if i create test1, and then do session.expunge_all, then immediately
> requery for session.query(Site).get(1), the returned instance is of type
> Test1, but trying to set the value for value1 yields 'Can't update table
> using NULL for primary key value'.
works for me:
test1 = TestOne(name='a test')
session.add(test1)
print session.query(Test).one()
session.expunge_all()
t = session.query(Test).one()
t.value1 = "value1"
session.commit()
output:
BEGIN (implicit)
INSERT INTO test (type, name) VALUES (?, ?)
('one', 'a test')
INSERT INTO test1 (id, value1) VALUES (?, ?)
(1, None)
SELECT test.id AS test_id, test.type AS test_type, test.name AS test_name,
test1.id AS test1_id, test1.value1 AS test1_value1, test2.id AS test2_id,
test2.value2 AS test2_value2
FROM test LEFT OUTER JOIN test1 ON test.id = test1.id LEFT OUTER JOIN test2 ON
test.id = test2.id
()
<__main__.TestOne object at 0x1014d7910>
SELECT test.id AS test_id, test.type AS test_type, test.name AS test_name,
test1.id AS test1_id, test1.value1 AS test1_value1, test2.id AS test2_id,
test2.value2 AS test2_value2
FROM test LEFT OUTER JOIN test1 ON test.id = test1.id LEFT OUTER JOIN test2 ON
test.id = test2.id
()
UPDATE test1 SET value1=? WHERE test1.id = ?
('value1', 1)
COMMIT
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SQLAlchemy sending a rollback after each commit
On Nov 13, 2012, at 12:28 PM, ckv wrote: > Thanks, I will stick to the default as it is not causing too much trouble. > > One more thing I have been noticing in the last couple of days is that a row > I'm querying in the database using filter_by() on three predicates and > limited by first() is being returned as None. I turned on mysql query logs > and then replayed the query printed for that exact attempt on my database and > the query returns one row fine. There is no apparent pattern to this > happening, as most of the times the query works fine and returns the result > object. > > Any idea why this would happen? It leads to some conditions of my daemon > failing and thereby freezing it. Any idea why this would happen? there may be a MySQL bug. a row not being returned under some circumstances sounds familiar but you'd have to search through http://bugs.mysql.com/ to see what it might be.or maybe the row isn't actually there yet due to some concurrency situation on your end, you'd have to keep investigating. > > On Sunday, November 11, 2012 2:12:44 AM UTC+5:30, Michael Bayer wrote: > > On Nov 10, 2012, at 3:04 PM, ckv wrote: > > > I am using SQLAlchemy for a multi-threaded daemon. MySQL is my backend. I > > use it in declarative mode with scoped_session and auto_commit set to > > False. Each thread requests for a scoped_session when it is spawned inside > > of the thread and then closes it when it is supposed to die. > > > > I see in my mysql query logs that there is a commit and then it is > > immediately followed by a rollback. > > > > Is this normal? > > yes, the connection pool has the behavior that a connection will have > .rollback() called on it before returning it to the pool, in the event that > any lingering state is left on the connection. If your Sessions are > unconditionally calling commit() at the very end, and nothing else, then > technically this rollback() isn't necessary. However, if you were to close() > a Session, or otherwise lose references to it before commit() or rollback() > were called, this rollback() makes sure that the connection is definitely > rolled back before going back to the pool. > > > Will this affect my performance in the long run? > > maybe. There is an option to disable this behavior, and specifically it's > handy if you're using MySQL MyISAM tables, which don't support transactions > anyway. We have had users report that this rollback() causes a little bit > of latency on MySQL, which is unfortunate since a transaction that is > essentially stateless shouldn't be having this issue. > > > > > I have been perf testing the daemon locally before pushing it to prod and > > wanted to get some pointers as to why this is happening. > > you can turn it off, or even have it do a commit() instead, using the > "reset_on_return" flag described at > "http://docs.sqlalchemy.org/en/rel_0_7/core/engines.html";. But if you set it > to None you really have to make sure your Sessions are closed cleanly, if > you're using InnoDB. > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/sqlalchemy/-/o812RI9YjPUJ. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] All column names renames: best practice?
On Nov 13, 2012, at 5:18 AM, Petr Blahos wrote: > I have been unlucky with mssql, where the first part - the table definition > and making queries worked, but not accessing data in RowProxy using the > key. I guess there is a bug in dialects/mssql/base.py > in MSSQLCompiler.visit_column: > > if result_map is not None: > result_map[column.name.lower()] = \ > -(column.name, (column, ), > +(column.name, (column, column.name, > column.key), > column.type) > > return super(MSSQLCompiler, self).\ thanks, this is http://www.sqlalchemy.org/trac/ticket/2607 in rcd9988751479 r0fe9fa12d4db (0.7) , you can get the tar.gz from "Development Versions" in : http://www.sqlalchemy.org/download.html -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Re: setattr + unmapped attribute
The behavior here isn't SQLAlchemy-specific. If you change: class MyClass(Base): __tablename__ = 'some_table' id = Column(Integer, primary_key=True) to class MyClass(object): pass , you will see the same behavior. On Tuesday, November 13, 2012 5:05:24 PM UTC-8, MikeParent wrote: > > With a mapped class instance, if I try and set an unmapped attribute, > Sqlalchemy simply adds this new attribute (locally) to the object, and > subsequent 'get' operations return the assigned value. > > Base = declarative_base() > > > class MyClass(Base): > > __tablename__ = 'some_table' > > id = Column(Integer, primary_key=True) > > >... > >obj = MyClass() >## This correctly raises 'AttributeError' >print obj.unmapped_attribute > >## This does not fail! >obj.unmapped_attribute = 0 >## Also does not fail anymore, prints "0" >print obj.unmapped_attribute > > I'd like to have an 'AttributeError thrown whenever I try and set a bad > property, similar to the getattr() behavior. Is this possible? Maybe I'm > doing something wrong? > > (Using SqlAlchemy 0.7.9, Python 2.7) > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/BVfDF3ECzI0J. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] Backref confusion
I have constructed a sample program consisting of two mapped classes (using sqlalchemy.ext.declarative) that have a relationship/ backref between them. At runtime the program does the following: 1) Print whether the parent class has an attribute for its relationship to the child (declared as the backref) 2) Construct a child object 3) Repeat step 1 The result (with SQLA 0.7.9) is that it prints 'False' during step 1 and then 'True' during step 3. I would expect True to be printed both times. Here is the full source of the program: https://gist.github.com/4070161 Why does the property not exist when the first print statement executes? Thanks for any guidance. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/SRZzsLt7qb0J. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] setattr + unmapped attribute
With a mapped class instance, if I try and set an unmapped attribute, Sqlalchemy simply adds this new attribute (locally) to the object, and subsequent 'get' operations return the assigned value. Base = declarative_base() class MyClass(Base): __tablename__ = 'some_table' id = Column(Integer, primary_key=True) ... obj = MyClass() ## This correctly raises 'AttributeError' print obj.unmapped_attribute ## This does not fail! obj.unmapped_attribute = 0 ## Also does not fail anymore, prints "0" print obj.unmapped_attribute I'd like to have an 'AttributeError thrown whenever I try and set a bad property, similar to the getattr() behavior. Is this possible? Maybe I'm doing something wrong? (Using SqlAlchemy 0.7.9, Python 2.7) -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/rAV73iowHsUJ. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
[sqlalchemy] automatically casting a class to a subclass via polymorphic discriminator?
I have a base class which has two subclasses specified via a polymorphic
discriminator, and I'm wondering how to set things up so the returned
results are instances of the subclass, when I create an instance of the
base class and assign the relevant value to the discriminator column.
Here's my example code:
import sys
from sqlalchemy import *
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm.attributes import instance_dict
from sqlalchemy.orm import relation, backref, class_mapper, create_session
e = create_engine('sqlite:tmp/foo.db', echo=True)
Base = declarative_base(bind=e)
class Test(Base):
__tablename__ = 'test'
id = Column(Integer, primary_key=True)
type = Column(String(12))
name = Column(String(50))
__mapper_args__ = {
'polymorphic_identity': 'base',
'polymorphic_on': type,
'with_polymorphic': '*',
}
class TestOne(Test):
__tablename__ = 'test1'
id = Column(Integer, ForeignKey('test.id'), primary_key=True)
value1 = Column(String(16))
__mapper_args__ = {
'polymorphic_identity': 'one',
}
class TestTwo(Test):
__tablename__ = 'test2'
id = Column(Integer, ForeignKey('test.id'), primary_key=True)
value2 = Column(String(16))
__mapper_args__ = {
'polymorphic_identity': 'two',
}
if __name__ == '__main__':
Base.metadata.drop_all()
Base.metadata.create_all()
session = create_session(bind=e, autocommit=False)
test1 = Test(type='one', name='a test')
session.add(test1)
print test1
This returns an instance of Test, not Test1, despite the discriminator
indicating that it should be cast as Test1.
Is it possible to handle this in a way which will yield an instance of
Test1?
Also, if i create test1, and then do session.expunge_all, then immediately
requery for session.query(Site).get(1), the returned instance is of type
Test1, but trying to set the value for value1 yields 'Can't update table
using NULL for primary key value'. Is there a way to fix this, so the
necessary table row is created with the same primary key, instead of
leaving it blank? It seems that all the info needed to handle the
auto-creation of the sub-table is present, but it just fails.
Thanks
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sqlalchemy/-/2GsqHNr52bsJ.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] SQLAlchemy sending a rollback after each commit
Thanks, I will stick to the default as it is not causing too much trouble. One more thing I have been noticing in the last couple of days is that a row I'm querying in the database using filter_by() on three predicates and limited by first() is being returned as None. I turned on mysql query logs and then replayed the query printed for that exact attempt on my database and the query returns one row fine. There is no apparent pattern to this happening, as most of the times the query works fine and returns the result object. Any idea why this would happen? It leads to some conditions of my daemon failing and thereby freezing it. Any idea why this would happen? On Sunday, November 11, 2012 2:12:44 AM UTC+5:30, Michael Bayer wrote: > > > On Nov 10, 2012, at 3:04 PM, ckv wrote: > > > I am using SQLAlchemy for a multi-threaded daemon. MySQL is my backend. > I use it in declarative mode with scoped_session and auto_commit set to > False. Each thread requests for a scoped_session when it is spawned inside > of the thread and then closes it when it is supposed to die. > > > > I see in my mysql query logs that there is a commit and then it is > immediately followed by a rollback. > > > > Is this normal? > > yes, the connection pool has the behavior that a connection will have > .rollback() called on it before returning it to the pool, in the event that > any lingering state is left on the connection. If your Sessions are > unconditionally calling commit() at the very end, and nothing else, then > technically this rollback() isn't necessary. However, if you were to > close() a Session, or otherwise lose references to it before commit() or > rollback() were called, this rollback() makes sure that the connection is > definitely rolled back before going back to the pool. > > > Will this affect my performance in the long run? > > maybe. There is an option to disable this behavior, and specifically > it's handy if you're using MySQL MyISAM tables, which don't support > transactions anyway. We have had users report that this rollback() causes > a little bit of latency on MySQL, which is unfortunate since a transaction > that is essentially stateless shouldn't be having this issue. > > > > > I have been perf testing the daemon locally before pushing it to prod > and wanted to get some pointers as to why this is happening. > > you can turn it off, or even have it do a commit() instead, using the > "reset_on_return" flag described at " > http://docs.sqlalchemy.org/en/rel_0_7/core/engines.html";. But if you set > it to None you really have to make sure your Sessions are closed cleanly, > if you're using InnoDB. > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/o812RI9YjPUJ. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] [Q] Move elements in one-to-many relationship to a new owner
Hello.
I was unable to reproduce the problem on your test example. I THINK it does
exactly what my problematic code does. It seems that either the problem is more
elaborate (but I don't see it) or I have a bug somewhere in my code. However my
simple workaround works, so I consider the problem solved, at least for now. I
will try to dig deeper when I have more time.
Ladislav Lenart
On 9.11.2012 23:22, Michael Bayer wrote:
> there's no mapping or code example provided here, which makes a condition
> like this extremely difficult to diagnose, however I've prepared a test
> script that takes its best guess as to configuration, that is, a
> client_products collection with a "client" backref, and a cascade of "all,
> delete-orphan" on the one-to-many which maximizes the conditions under which
> a ClientProduct might be deleted. The test case below does not exhibit this
> behavior; please alter it such that it reproduces the condition you are
> seeing so that we can diagnose this fully and ensure you aren't coming across
> any new SQLAlchemy bugs:
>
>
> from sqlalchemy import *
> from sqlalchemy.orm import *
> from sqlalchemy.ext.declarative import declarative_base
>
> Base = declarative_base()
>
> class Client(Base):
> __tablename__ = "a"
>
> id = Column(Integer, primary_key=True)
> data = Column(String)
> client_products = relationship("ClientProduct",
> backref='client',
> cascade="all, delete-orphan")
>
>
> class ClientProduct(Base):
> __tablename__ = "b"
>
> id = Column(Integer, primary_key=True)
> data = Column(String)
> a_id = Column(Integer, ForeignKey('a.id'))
>
> e = create_engine("sqlite://", echo=True)
>
> Base.metadata.create_all(e)
>
> s = Session(e)
>
>
> s.add_all([
> Client(data='c1', client_products=[
> ClientProduct(data='cp1'),
> ClientProduct(data='cp2'),
> ClientProduct(data='cp3'),
> ]),
> Client(data='c2', client_products=[
> ClientProduct(data='cp4'),
> ClientProduct(data='cp5'),
> ClientProduct(data='cp6'),
> ]),
> ])
> s.commit()
>
>
> c1 = s.query(Client).filter_by(data='c1').one()
> c2 = s.query(Client).filter_by(data='c2').one()
>
> cp1, cp2 = c1.client_products[0:2]
>
> cp1.client = c2
> cp2.client = c2
> s.delete(c1)
> s.commit()
>
> assert s.query(Client.data).all() == [('c2',)]
> assert s.query(ClientProduct.data).all() == [('cp1', ), ('cp2', ), ('cp4', ),
> ('cp5', ), ('cp6', )]
>
>
>
>
> On Nov 8, 2012, at 11:30 AM, Ladislav Lenart wrote:
>
>> Hello.
>>
>> I have a client which has a collection of ClientProduct-s (ClientProduct has
>> a
>> FK to Client). The following code:
>>
>># Move some client products from a duplicate to the original.
>># Remove duplicate clients afterwards (in cascade).
>>#
>># Note that client_map is a dict from a duplicate to its original.
>>for each_duplicate, each_client in client_map.iteritems():
>>for each_cp in each_duplicate.client_products:
>>if some_condition(each_cp):
>>each_cp.client = each_client
>>session.delete(each_duplicate)
>>session.flush()
>>
>> deletes a client product that was moved from each_duplicate to each_client in
>> the inner loop. Why? What can I do to prevent it?
>>
>>
>> Thank you in advance,
>>
>> Ladislav Lenart
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To post to this group, send email to sqlalchemy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sqlalchemy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
Re: [sqlalchemy] All column names renames: best practice?
>
> the company I worked for has decided to change a RDBMS behind our ERP.
> The side effect of this is that the columns will no longer be prefixed
> with *t$*
> but with* t_* instead. I do not want to change all the occurences of
> column
> names in my code. I should also mention, that I use only selects, and no
> ORM.
>
> [...]
>
>
> But I'd probably not be using that approach either.Column objects
> support a "key" field so that they need not be referenced in code in the
> same way the relational database does; one of the primary purposes of
> Column is to allow symbolic names to prevent the issue of needing to
> "change all occurrences" of any schema-related name in code:
>
> my_table = Table('some_name', metadata, Column('t$somename', Integer,
> key='somename'))
>
>
Thanks for the pointers Mike. Just to clarify: The first argument to Column
is
the real name of the column in the database, while key is an alternative
name
under which I can access it, right?
I have been unlucky with mssql, where the first part - the table definition
and making queries worked, but not accessing data in RowProxy using the
key. I guess there is a bug in dialects/mssql/base.py
in MSSQLCompiler.visit_column:
if result_map is not None:
result_map[column.name.lower()] = \
-(column.name, (column, ),
+(column.name, (column, column.name,
column.key),
column.type)
return super(MSSQLCompiler, self).\
(also attaching...)
Thanks again.
--
Petr
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
a.diff
Description: Binary data
[sqlalchemy] with_polymorphic query and parent attribute filtering
Hi,
I'm using polymorphism for some of my models and I'm wondering how I
should use the with_polymorphic query method.
Consider the following:
"""
class A(Base):
type_ = Column(Integer, nullable=False)
arg = Column(String(20))
__mapper_args__ = {'polymorphic_on': type_, 'polymorphic_identity': 0}
class B(A):
__mapper_args__ = {'polymorphic_identity': 1}
class C(A):
__mapper_args__ = {'polymorphic_identity': 2}
class D(A):
__mapper_args__ = {'polymorphic_identity': 3}
"""
When I query :
"""
session.query(A).with_polymorphic([B,C]).filter(A.arg == 'test')
"""
I get D elements in my result.
I've tried :
"""
session.query(A).with_polymorphic([B,C]).filter(or_(B.arg=='test',
C.arg=='test'))
"""
But it doesn't work neither.
Could somebody explain me what I did wrong and how I should do ?
Regards
Gaston
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
