[sqlalchemy] Strange lazy-load query

2011-03-07 Thread Joril
Hi everyone!

I have an object graph like this:

Invoice - Detail (one-to-many with cascade) - Product (many-to-one) -
 VAT (many-to-one)

My problem is that sometimes if I have a Detail and try to read its
Product, the triggered lazy-loading generates a query more complicated
than necessary, having a LEFT OUTER JOIN on the VAT table too... Other
times the lazy-loading query joins only Detail and Product.
I think I'm doing something fishy here.. What could I check, to ensure
that the lazy loading doesn't touch unneeded entities?

Many thanks!

(SQLAlchemy 0.6.6, PGSQL 8.3)

-- 
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] Strange lazy-load query

2011-03-07 Thread Michael Bayer
the left outer join means there is a lazy=False or lazy='joinedload' on the 
relationship, or in this case since its sporadic, the parent Invoice is likely 
being loaded with an option like joinedload(Product.vat).The options 
specified in Query get attached to lazy loaders later in the chain, if the 
given joinedload() chain doesn't start from the entity being queried (which is 
probably the case if the query uses joinedload() and not joinedload_all()).   
For those Product objects already in the identity map, this option would not 
take place.


On Mar 7, 2011, at 8:13 AM, Joril wrote:

 Hi everyone!
 
 I have an object graph like this:
 
 Invoice - Detail (one-to-many with cascade) - Product (many-to-one) -
 VAT (many-to-one)
 
 My problem is that sometimes if I have a Detail and try to read its
 Product, the triggered lazy-loading generates a query more complicated
 than necessary, having a LEFT OUTER JOIN on the VAT table too... Other
 times the lazy-loading query joins only Detail and Product.
 I think I'm doing something fishy here.. What could I check, to ensure
 that the lazy loading doesn't touch unneeded entities?
 
 Many thanks!
 
 (SQLAlchemy 0.6.6, PGSQL 8.3)
 
 -- 
 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.



[sqlalchemy] Re: overriding DeclarativeBase and descriptors

2011-03-07 Thread farcat
thanks, I will start experimenting ...

On Mar 5, 4:52 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 On Mar 5, 2011, at 10:43 AM, farcat wrote:









  Hi,

  I am trying to implement polymorphism and multiple inheritance by:

  - adding a column to the parent class/table indicating the table from
  which the (polymorphic) class attribute object can be queried
  - adding the attribute name and the parent id to the child table/class
  to be able to find the attribute object in this table

  Now i want to use a descriptor and/or override __getattr__/__setattr__/
  __getattribute__ to insert or get the correct (polymorphic) object
  from the correct table.

  What I was wondering was e.g. whether using a descriptor will inhibit
  SA from functioning correctly. Any tips to implement what i am trying
  to do would be very welcome.

 SQLAlchemy uses descriptors for all the mapped attributes and has several 
 avenues to augmenting them with your own descriptors.  __getattribute__ and 
 __setattr__ work as expected, as does __getattr__ although that only applies 
 to names that otherwise don't exist on the object.

 We encourage an extremely simple approach to descriptor access which is to 
 name the columns in one way, and the descriptor in another.    The synonym 
 construct does this as does the newer hybrid attribute approach. Set and 
 delete events can also be intercepted using the events module (new in 0.7 - 
 in 0.6 use AttributeExtension).









  Cheers, Lars

  --
  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 
  athttp://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.



[sqlalchemy] difference for type BigInteger between 0.6.6 and 0. 7.0b2

2011-03-07 Thread Mike Bernson

from sqlalchemy import *

meta = MetaData()

stx_setup = Table(stx_setup, meta,
Column('id', BigInteger(display_width=20), primary_key=True, autoincrement=T
rue),
Column('cost_center', Integer(display_width=1), index=True, nullable=True),
Column('AdministratorLicense', String(length=16), nullable=True),
Column('MDDOLicense', String(length=16), nullable=True),
Column('DONLicense', String(length=16), nullable=True),
Column('AssessorLicense', String(length=16), nullable=True),
Column('VendorNumber', String(length=4), nullable=True),
Column('ContractNumber', String(length=9), nullable=True),
Column('HospiceContractNumber', String(length=9), nullable=True),
Column('ServiceGroup', String(length=1), nullable=True),
)

The above code work in 0.6.6 and gives an following error in 0.7b2
Traceback (most recent call last):
  File simple.py, line 6, in module
Column('id', BigInteger(display_width=20), primary_key=True, 
autoincrement=True),
TypeError: __init__() got an unexpected keyword argument 'display_width'

Did not see anything in the 0.7 migration notes about this.

Is this a bug ?


--
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] difference for type BigInteger between 0.6.6 and 0. 7.0b2

2011-03-07 Thread Michael Bayer
display_width is a MySQL option so you'd want to use 
sqlalchemy.dialects.mysql.BIGINT / mysql.INTEGER for that.   Not sure why 
0.6.6's base BigInteger type allows it.


On Mar 7, 2011, at 5:38 PM, Mike Bernson wrote:

 from sqlalchemy import *
 
 meta = MetaData()
 
 stx_setup = Table(stx_setup, meta,
Column('id', BigInteger(display_width=20), primary_key=True, 
 autoincrement=T
 rue),
Column('cost_center', Integer(display_width=1), index=True, nullable=True),
Column('AdministratorLicense', String(length=16), nullable=True),
Column('MDDOLicense', String(length=16), nullable=True),
Column('DONLicense', String(length=16), nullable=True),
Column('AssessorLicense', String(length=16), nullable=True),
Column('VendorNumber', String(length=4), nullable=True),
Column('ContractNumber', String(length=9), nullable=True),
Column('HospiceContractNumber', String(length=9), nullable=True),
Column('ServiceGroup', String(length=1), nullable=True),
 )
 
 The above code work in 0.6.6 and gives an following error in 0.7b2
 Traceback (most recent call last):
  File simple.py, line 6, in module
Column('id', BigInteger(display_width=20), primary_key=True, 
 autoincrement=True),
 TypeError: __init__() got an unexpected keyword argument 'display_width'
 
 Did not see anything in the 0.7 migration notes about this.
 
 Is this a bug ?
 
 
 -- 
 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.



[sqlalchemy] Declarative Class registry ?

2011-03-07 Thread James Mills
Hello,

Given a scenario where you're using declarative_base(...) and defining 
classes

Is there a way to ask SA what the mapper class (declarative) is for a given 
table
by inspecting something in metadata[table_name] ?

cheers
James


-- 
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.