[sqlalchemy] Re: Bulk creation of columns

2011-09-22 Thread pravin battula
 You need to create new Column objects for each table because the table 
 objects take ownership of the passed in columns.
I think that is what i'm doing,creating new column objects for 2
columns and first appending it to the table object and then trying to
create those columns using create_column,please correct me if i'm
wrong.




On 21 Sep, 20:24, AM age...@themactionfaction.com wrote:
 On Sep 21, 2011, at 6:30 AM, pravin battula wrote:
  Hi,

  How can i create columns in bulk?
  I tried as below but doesn't work.

     migrate_engine = create_engine('mysql://root:root@localhost/
  payroll', echo=False)
     metadata = MetaData(bind = migrate_engine)
     metadata.reflect(bind = migrate_engine, schema = 'payroll')

     tableObj = metadata.tables.get('test.salary')

     colList =
  [Column('description',String(100)),Column('information',String(50))]

     tableObj.append_column(colList)
     tableObj.create_column(colList)

 You need to create new Column objects for each table because the table 
 objects take ownership of the passed in columns.

 Cheers,
 M

-- 
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] Re: object_session returns None, but state still has session_id

2011-09-22 Thread Ben Ford
Hi Mike,

It is an edge case for sure. I'm using SA with eventlet so the session is 
going out of scope in a green thread. Eventlet does some monkeying 
(literally) around with threadlocals so I get a different session for each 
one. However in this case the parent instance to which I'm adding obj was 
fetched in a one greenthread and the child is added in another after a timer 
has fired off (the child is a record of the timer running). It's definitely 
fair to say that I'm not using SA in an optimal way, however I'd still be 
inclined to say that the patch could be worthwhile here.

I should also have mentioned that the original session would have been from 
a query_property rather than an explicitly created Session().

Is there any particular reason that you added the check where you did in the 
patch as opposed to the except KeyError clause in _state_session?

Cheers,
Ben

-- 
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/-/HfGgOzhCMwIJ.
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] Bulk creation of columns

2011-09-22 Thread King Simon-NFHD78
 -Original Message-
 From: sqlalchemy@googlegroups.com [mailto:sqlalchemy@googlegroups.com]
 On Behalf Of pravin battula
 Sent: 21 September 2011 12:54
 To: sqlalchemy@googlegroups.com
 Subject: [sqlalchemy] Bulk creation of columns
 
 Hi,
 
 
 How can i create columns in bulk using create_column  method?
 
 
 I tried as below,.
 
 migrate_engine = create_engine('mysql://root:root@localhost/
 payroll', echo=False)
 metadata = MetaData(bind = migrate_engine)
 metadata.reflect(bind = migrate_engine, schema = 'payroll')
 
 
 tableObj = metadata.tables.get('test.salary')
 
 
 colList =
 [Column('description',String(100)),Column('information',String(50))]
 
 
 tableObj.append_column(*colList)
 tableObj.create_column(*colList)
 
 
 getting an error as TypeError:create() got multiple values for
 keyword argument 'table'
 
 Please do the needful.
 

create_column isn't an SQLAlchemy method as far as I know. Are you using
something like sqlalchemy-migrate
(http://code.google.com/p/sqlalchemy-migrate/)?

If so, you'll probably get more help on their mailing list.

Hope that helps,

Simon

-- 
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] Re: object_session returns None, but state still has session_id

2011-09-22 Thread Michael Bayer

On Sep 22, 2011, at 5:04 AM, Ben Ford wrote:

 Hi Mike,
 
 It is an edge case for sure. I'm using SA with eventlet so the session is 
 going out of scope in a green thread. Eventlet does some monkeying 
 (literally) around with threadlocals so I get a different session for each 
 one. However in this case the parent instance to which I'm adding obj was 
 fetched in a one greenthread and the child is added in another after a timer 
 has fired off (the child is a record of the timer running). It's definitely 
 fair to say that I'm not using SA in an optimal way, however I'd still be 
 inclined to say that the patch could be worthwhile here.

I'm going to do the patch since that's how I'd like it to work, but that is the 
least of your problems here, if you're linking the scope of your sessions to a 
library that is repurposing threading to be a system of supplying ad-hoc, 
transitory context to a longer series of operations.  There's nothing wrong 
with that approach from a threading point of view, but with this repurposing, 
it's no longer appropriate to link an operation-scoped object like Session to a 
thread.

You need to use a contextual callable with scoped_session() that links the 
lifespan of a Session to the lifespan of the series of objects you're working 
with - it accepts an argument scopefunc - this is a function that should 
return a key, usually a string but can be anything hashable, that represents 
this is the current context.   For example, if the function was 
threading.get_ident(), you'd get thread local behavior.

I usually use what I call the dinner party metaphor here, the set of objects 
you're dealing with is your meal, the Session is the plate.   You don't want to 
keep switching plates for every bite, chucking the previous plate onto the 
floor with whatever is still stuck to it.   You want to receive your plate, 
finish your meal, then return the plate.   The thread is usually the dinner 
guest here but your guest is busy performing on stage, so you need to invite a 
new guest who knows how to dine properly.

The Session is linked to an ongoing transaction in the database, unless you've 
turned that off with autocommit=True, and your app should be able to keep track 
of such a concept, even if eventlet is switching around threads underneath.

If this is going to go the other way, where none of that is possible, then you 
should be disabling most of Session's automation, turning on autocommit, 
turning off expire_on_commit, turning off autoflush.  Randomly switching 
sessions among any subset of objects in a connected graph is generally going to 
create havoc in any case though.

 
 
 Is there any particular reason that you added the check where you did in the 
 patch as opposed to the except KeyError clause in _state_session?

The _attach() method of Session, the point at which we determine if an owning 
Session still exists, doesn't call _state_session().  If you mean why don't we 
call _state_session() there for the purposes of encapsulation of the session_id 
attribute, that would imply the whole middle of _attach() just calls 
_state_session(), which introduces additional function call overhead in a 
fairly critical section.  _attach() needs to be aware of session_id in any case 
so it's IMHO fine that it interprets this attribute fully.

SQLAlchemy's code is necessarily inlined in many places due to Python's 
tremendous function call overhead, some background on that (skip down to the 
second section, the first half is just wanking) is at 
http://techspot.zzzeek.org/2010/12/12/a-tale-of-three-profiles/ .

-- 
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] SQLAchemy architecture in slides

2011-09-22 Thread Victor Olex
It is worth mentioning that Mike has published slides from his
PyGotham talk on SQLAlchemy architecture, which also covered certain
internal algorithms.

http://techspot.zzzeek.org/2011/09/16/sqlalchemy-at-pygotham/

I am looking forward to watching the video, which should help me get a
grasp of the unit of work dependency resolution algorithm.

Thanks,

Victor
http://linkedin.com/in/victorolex
http://twitter.com/in/agilevic

-- 
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] using @declared_attr to define a column in an actual class (non-mixin)

2011-09-22 Thread Yap Sok Ann
With this code:

from sqlalchemy.ext.declarative import declarative_base, declared_attr
from sqlalchemy.schema import Column
from sqlalchemy.types import Integer, String

Base = declarative_base()


class Mixin(object):
@declared_attr
def attr2(cls):
return Column(String(20), nullable=False)


class Test(Base, Mixin):
__tablename__ = 'test'

id = Column(Integer, primary_key=True)

@declared_attr
def attr1(cls):
return Column(String(20), nullable=False)


if __name__ == '__main__':
print Test.attr1.__class__
print Test.attr2.__class__


Test.attr1 will be a sqlalchemy.schema.Column, while Test.attr2 will
be a sqlalchemy.orm.attributes.InstrumentedAttribute. Why are they
behave differently?

Anyway, what I want to achieve is to selectively define a column based
on some external flag, so I was trying to put in if..else block inside
@declared_attr to return either None or Column. Is there a better way
to do it, e.g. using a metaclass?

Thanks.

-- 
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] using @declared_attr to define a column in an actual class (non-mixin)

2011-09-22 Thread Michael Bayer
@declared_attr when used for attributes outside of __table_args__, 
__tablename__ and __mapper_args__ is only recognized on a mixin, or on a class 
that uses a new directive __abstract__ = True.  It's skipped on mapped 
classes when used for plain column attributes since inheriting from a mapped 
class means you're using mapper inheritance - and in the usual case of single- 
or joined-table inheritance, the subclass specifically should not get copies of 
columns on the superclass.   So really @declared_attr returning a column on the 
mapped class should be raising an error here, perhaps I'll make it emit a 
warning for the time being since it will not do anything useful.

If you'd like to put a non-mixin class in the middle of your hierarchy that can 
define columns that immediate subclasses should have, use the tip of 0.7 (0.7.3 
not released yet) and put the directive __abstract__ = True on the class - 
the @declared_attr's on columns should be recognized in that case.   You 
wouldn't want to have __tablename__ = 'test' on such a class either since it 
isn't mapped.



On Sep 23, 2011, at 12:48 AM, Yap Sok Ann wrote:

 With this code:
 
 from sqlalchemy.ext.declarative import declarative_base, declared_attr
 from sqlalchemy.schema import Column
 from sqlalchemy.types import Integer, String
 
 Base = declarative_base()
 
 
 class Mixin(object):
@declared_attr
def attr2(cls):
return Column(String(20), nullable=False)
 
 
 class Test(Base, Mixin):
__tablename__ = 'test'
 
id = Column(Integer, primary_key=True)
 
@declared_attr
def attr1(cls):
return Column(String(20), nullable=False)
 
 
 if __name__ == '__main__':
print Test.attr1.__class__
print Test.attr2.__class__
 
 
 Test.attr1 will be a sqlalchemy.schema.Column, while Test.attr2 will
 be a sqlalchemy.orm.attributes.InstrumentedAttribute. Why are they
 behave differently?
 
 Anyway, what I want to achieve is to selectively define a column based
 on some external flag, so I was trying to put in if..else block inside
 @declared_attr to return either None or Column. Is there a better way
 to do it, e.g. using a metaclass?
 
 Thanks.
 
 -- 
 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.