[sqlalchemy] Re: Beta6 - sqlsoup - SADeprecationWarning

2007-09-28 Thread Catalin Constantin

Hello,

It's inside sqlsoup :)
This is all i do in my script:

engine = create_engine(config.SQL_DSN, pool_size=config.THREADS_NO,
poolclass=pool.QueuePool)
db = SqlSoup(MetaData(engine))

Is this a thing on the TODO list (eg: update sqlsoup in Beta) ?


On 9/28/07, Andreas Jung [EMAIL PROTECTED] wrote:


 --On 27. September 2007 20:43:30 -0700 Catalin Constantin
 [EMAIL PROTECTED] wrote:

 
  Hello,
 
  I get the following warning message, after the upgrade to 0.4 beta6.
 
  /usr/lib/python2.4/site-packages/SQLAlchemy-0.4.0beta6-py2.4.egg/
  sqlalchemy/ext/sqlsoup.py:356: SADeprecationWarning: SessionContext is
  deprecated.  Use scoped_session().
 
  Is there any quickfix ?
 

 The warning message is very clear: use scoped_session().

 -aj



-- 
Catalin Constantin
Dazoot Software
http://www.dazoot.eu/

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: aliased tables

2007-09-28 Thread Glauco
Roger Demetrescu ha scritto:
 On 9/27/07, Glauco [EMAIL PROTECTED] wrote:
   
  Glauco, can you send a small test script reproducing the error ?

 I'll gladly take a look at that...

 Cheers,

 Roger



  Yes...

  this is the example



  session.query( UnitaAziendale ).order_by(Anagrafica.c.nome)
 

 SNIP


 Thanks Glauco...

 But you forgot your Tables and mappers definition...  ;)
   

isn't forgotten...
i dont' have table definition in SA but use reverse engeenering over an 
existing  DB,
and this mapper are huge...
anyway i try to give an idea with only some example of base table 
implied in this example.

Table(u'unita_aziendale',
DynamicMetaData(),
Column(u'id',PGInteger(),primary_key=True,nullable=False,default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb6fdf06c)),
Column(u'id_azienda',PGInteger(),ForeignKey(u'azienda.id'),nullable=False),
Column(u'id_anagrafica',PGInteger(),ForeignKey(u'anagrafica.id')),
Column(u'codice_struttura',PGText(length=None,convert_unicode=False)),
Column(u'bdn_id',PGInteger()),
Column(u'bdn_data_ultima_modifica',PG2Date()),
Column(u'bdn_specie',PGChar(length=4,convert_unicode=False)),
Column(u'bdn_flag_carne_latte',PGChar(length=1,convert_unicode=False)),
Column(u'data_inizio',PG2Date()),Column(u'data_fine',PG2Date()),
Column(u'id_precedente',PGInteger(),ForeignKey(u'unita_aziendale.id')),
Column(u'ts_ultima_modifica',PG2DateTime(timezone=False),default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb6fdf98c)),
Column(u'id_operatore',PGInteger(),ForeignKey(u'operatore.id')),
Column(u'stato_record',PGChar(length=1,convert_unicode=False),default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb6fdfacc)),schema=None)


Table(u'anagrafica',
DynamicMetaData(),
Column(u'id',PGInteger(),primary_key=True,nullable=False,default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb702390c)),
Column(u'nome',PGText(length=None,convert_unicode=False)),
Column(u'indirizzo',PGText(length=None,convert_unicode=False)),
Column(u'telefono',PGText(length=None,convert_unicode=False)),
Column(u'email',PGText(length=None,convert_unicode=False)),
Column(u'id_comune',PGInteger(),ForeignKey(u'comune.id')),
Column(u'localita',PGText(length=None,convert_unicode=False)),
Column(u'cap',PGText(length=None,convert_unicode=False)),
Column(u'dato_fiscale',PGText(length=None,convert_unicode=False)),
Column(u'cod_nazionalita',PGChar(length=3,convert_unicode=False),ForeignKey(u'nazione.codice')),
Column(u'data_nascita',PG2Date()),Column(u'id_comune_nascita',PGInteger(),ForeignKey(u'comune.id')),
Column(u'cod_nazione_nascita',PGChar(length=3,convert_unicode=False),ForeignKey(u'nazione.codice')),
Column(u'id_precedente',PGInteger(),ForeignKey(u'anagrafica.id')),
Column(u'ts_ultima_modifica',PG2DateTime(timezone=False),default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb70291cc)),
Column(u'id_operatore',PGInteger(),ForeignKey(u'operatore.id')),
Column(u'stato_record',PGChar(length=1,convert_unicode=False),default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb702930c)),
Column(u'tipo',PGChar(length=1,convert_unicode=False),nullable=False,default=PassiveDefault(sqlalchemy.sql._TextClause
 
object at 0xb70293cc)),
Column(u'cod_professione',PGChar(length=3,convert_unicode=False),ForeignKey(u'professione.codice')),
Column(u'cod_titolo_studio',PGChar(length=3,convert_unicode=False),ForeignKey(u'titolo_studio.codice')),schema=None)





assign_mapper(context,
  UnitaAziendale,
  tbl['unita_aziendale'],
  column_prefix=unita_aziendale_,
  extension = SelectResultsExt(),
  properties = { 'anagrafica'   : 
relation(Anagrafica, lazy=False),
 'figure'   : 
relation(FiguraAziendale, backref='unita_aziendale'),
 'produzioni'   : 
relation(Produzione, backref='unita_aziendale'),
 'azienda_veterinario'  : 
relation(AziendaVeterinario, 
primaryjoin=tbl['azienda_veterinario'].c.id_unita_aziendale == 
tbl['unita_aziendale'].c.id),
 'peso' : 
relation(SchedaTotali),
 })


assign_mapper(context,
  Anagrafica,
  tbl['anagrafica'],
  column_prefix = 'anagrafica_',
  extension = SelectResultsExt(),
  properties = {
'comune' : relation( Comune,
   primaryjoin = tbl['anagrafica'].c.id_comune == 
tbl['comune'].c.id ),
'nazione': relation( Nazione,
   primaryjoin = tbl['anagrafica'].c.cod_nazionalita == 
tbl['nazione'].c.codice ),
'comune_nascita' : relation( Comune,
   primaryjoin = tbl['anagrafica'].c.id_comune_nascita 
== tbl['comune'].c.id),
'nazione_nascita' : relation(Nazione,
   primaryjoin = 

[sqlalchemy] Re: polymorphic question

2007-09-28 Thread sdobrev

On Friday 28 September 2007 01:14:32 Michael Bayer wrote:
 On Sep 27, 2007, at 3:53 PM, [EMAIL PROTECTED] wrote:
  i know in 0.4 one can request a polymorphic request to be
  automaticaly split into multiple per-subtype requests. i've no
  idea how this compares +/- to the huge union/outerjoin that gives
  all in one long shot.
 
  my question is.. can this mechanism/approach be used somehow for
  (semi) automatic vertical loading, i.e. instead of loading all
  items in all rows, load only some items normaly while
  (pre)loading some specific columns in whole in one separate shot?
  say there is a table X having a,b,c..p,q. So i do a plain row
  query over X, getting a,b,c,d per row, and request the p and q
  columns (pre)loaded whole (or partial as per some limit).
  i imagine this to be useful to avoid zillions of eagerloads/joins
  etc (when the columns in question are links to somewhere).
  but i might be wrong... - i've no idea how the eagerloading
  scales. Any arguments pro/con?

 if youre talking about just one table X, deferred columns will
 hold off the loading of those columns until they are accessed.  as
 far as the joined tables, polymorphic_fetch=deferred will leave
 those to be loaded when those attributes are first accessed. 
 that's as well as I understand your question so far
mmm no, i'm not asking that. 
is there any available mechanism to load a query by columns instead of 
by rows. that is split a query verticaly. like paginate verticaly and 
not just horizontaly. Think a table with rows and many columns. 
usualy query yields full rows. i want to split the query into 
several, each having a number (=1) of columns of the whole thing, 
all under same filtering, one being the leading one, others loaded 
per request, in big chunks).
nevermind, it won't be hard to make anyway, once i know exacty what i 
need

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: before_update mapper extension behavior?

2007-09-28 Thread Michael Bayer


On Sep 28, 2007, at 3:08 AM, Aaron R wrote:


 Hello;

 Does anyone know what the behavior for the before_update and
 before_insert methods of a mapper that is extended should be?  From
 the code below, if i add a child object to an item being saved during
 a before_insert that has a mapper extension it is not saved, but is if
 session.save() is subsequently called?   However changes made to the
 core attributes are saved, just not list items.  Is that the expected
 behavior?  If so is there an earlier event to catch and do an
 equivalent?


the before_insert() and before_update() methods are called in the  
context of an ongoing flush() operation.  inside of flush(), the full  
graph of objects to be inserted/updated/deleted has already been  
determined, so you cannot affect that graph within before_insert or  
before_update.  changes which you make to the session at that stage  
wont get picked up until the next flush.

however, the column-based attributes present on the instance itself  
have not yet been inserted/updated into the DB, and the fact that the  
instance is being sent to before_update() indicates that it has in  
fact already been marked as dirty and is to be updated.  So  
whatever column-attribute changes you make within before_update to  
the local instance will be reflected in the immediately proceeding  
SQL statement.

if youd like to make changes to the total graph of objects before a  
flush, theres a SessionExtension object you can use in version 0.4 in  
order to add hooks to the flush process.




--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] ORDER_BY always in SELECT statements?

2007-09-28 Thread [EMAIL PROTECTED]

Hi,

While trying to debug my script I set echo=True and checked the SQL
statements that are generated. I noticed that all of the SELECTs
issued to the DB have the ORDER_BY clause -- even though I didn't
explicitly specify order_by() nor do I care about the order.

Is this normal? Is there any way to turn this off?

Thanks in advance,
Mark


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: ORDER_BY always in SELECT statements?

2007-09-28 Thread Michael Bayer


On Sep 28, 2007, at 3:00 PM, [EMAIL PROTECTED] wrote:


 Hi,

 While trying to debug my script I set echo=True and checked the SQL
 statements that are generated. I noticed that all of the SELECTs
 issued to the DB have the ORDER_BY clause -- even though I didn't
 explicitly specify order_by() nor do I care about the order.

 Is this normal? Is there any way to turn this off?

im assuming youre talking about mappers.  specify order_by=None in  
the mapper() (and in relation()s) to turn off the default ordering.



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: before_update mapper extension behavior?

2007-09-28 Thread Jonathan LaCour

Michael Bayer wrote:

 however, the column-based attributes present on the instance itself
 have not yet been inserted/updated into the DB, and the fact that
 the instance is being sent to before_update() indicates that it has
 in fact already been marked as dirty and is to be updated.  So
 whatever column-attribute changes you make within before_update to the
 local instance will be reflected in the immediately proceeding SQL
 statement.

Is there any way to determine why an object as been marked as dirty by
asking the session?  The reason I ask is because sometimes objects which
have had none of their column-based attributes modified are marked as
dirty as the result of something that has happened on a relation.  It
would be nice to know in my before_update() *why* the object is dirty
without having to query the database for the current column values and
do comparisons.

Just curious if this is possible...

--
Jonathan LaCour
http://cleverdevil.org


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: before_update mapper extension behavior?

2007-09-28 Thread Michael Bayer


On Sep 28, 2007, at 5:22 PM, Jonathan LaCour wrote:


 Michael Bayer wrote:

 however, the column-based attributes present on the instance itself
 have not yet been inserted/updated into the DB, and the fact that
 the instance is being sent to before_update() indicates that it has
 in fact already been marked as dirty and is to be updated.  So
 whatever column-attribute changes you make within before_update to  
 the
 local instance will be reflected in the immediately proceeding SQL
 statement.

 Is there any way to determine why an object as been marked as dirty by
 asking the session?  The reason I ask is because sometimes objects  
 which
 have had none of their column-based attributes modified are marked as
 dirty as the result of something that has happened on a relation.  It
 would be nice to know in my before_update() *why* the object is dirty
 without having to query the database for the current column values and
 do comparisons.

 Just curious if this is possible...

i just added it to before_update's docstring today:

session.is_modified(instance, include_collections=False)

and you can get the session using object_session(instance).

I know this is relevant to your versioning extension since Ben and I  
had a day of it last week  :)



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: before_update mapper extension behavior?

2007-09-28 Thread Jonathan LaCour

Michael Bayer wrote:

 i just added it to before_update's docstring today:

 session.is_modified(instance, include_collections=False)

 and you can get the session using object_session(instance).

 I know this is relevant to your versioning extension since Ben and I
 had a day of it last week  :)

Excellent :) Yes, Ben and I talked about it, and I am really glad to see
that there is a nice way to deal with this now!  Thanks!

--
Jonathan LaCour
http://cleverdevil.org


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] one-to-many access and modification

2007-09-28 Thread Ken Pierce

Hello all,

I just got into using sqlalchemy today and I have a question about
accessing data in a one-to-many relationship.

I've got a simplified example below. Basically the system is for a
group of us voting on DVDs we want to rent. There are users and films
and for each film a user makes a yes / no choice (where ? is
undecided).

# create tables
users_table = Table('users', metadata,
Column('id', Integer, primary_key=True),
Column('name', String(40)),
mysql_engine='InnodB')

films_table = Table('films', metadata,
Column('fid', Integer, primary_key=True),
Column('title', String(128)),
mysql_engine='InnodB')

choices_table = Table('choices', metadata,
Column('fid', Integer, ForeignKey('films.fid'), primary_key=True),
Column('id', Integer, ForeignKey('users.id'), primary_key=True),
Column('choice', MSEnum('?','Y','N')),
mysql_engine='InnodB')

# classes here
class User(object):
...
class Film(object):

class Choice(object):


# mappers
mapper(User, users_table)
mapper(Film, films_table, properties={'choices':relation(Choice)})
mapper(Choice, choices_table)

So, if I retrieve a Film object f, f.choices gives me a list of Choice
objects. From that Film object, I want to look up (and possibly
modify) a users choice.

My question is, is there a way to set up this relationship so that I
could access a users choice like a dictionary (either with a user id
or User object), or do I have to write a method to search the list and
return the object -- in which case, would the changes be reflected in
the session / database?

Thanks in advance,
Most impressed so far,

Ken Pierce.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: aliased tables

2007-09-28 Thread Roger Demetrescu

On 9/28/07, Glauco [EMAIL PROTECTED] wrote:
  Yes...

  this is the example



  session.query( UnitaAziendale ).order_by(Anagrafica.c.nome)


Ok... do you remember about  the .join() or .outerjoin() I told you before ?
That's how you should declare you Query:



q = session.query( UnitaAziendale
).outerjoin('anagrafica').order_by(Anagrafica.c.nome)

OR

q = session.query( UnitaAziendale
).join('anagrafica').order_by(Anagrafica.c.nome)



Then try printing the q.compile()

You will see a join between unita_aziendale and anagrafica
(twice)... One of these anagrafica joins is to provide you the
columns regarding 'anagrafica' property... The other anagrafica join
is because we will force SA to make this join, so we can order by
(Anagrafica.c.nome).


Why can SA use the same 'anagrafica' join to give us the columns and
to provide the order by clause ? - you may ask...

One of the reasons is because you can always change the rules about a
Query... like: what if I don't need to eagerload the 'anagrafica'
objects ?


q = session.query(UnitaAziendale).options(lazyload('anagrafica'))
q = q.outerjoin('anagrafica').order_by(Anagrafica.c.nome)
print q.compile()


See ? No anon_ prefix this time.. because you told SA to just
query UnitaAziendale objects... (but ordering by another table column)

Try swapping the .outerjoin('anagrafica') for .join('anagrafica')
and see the differences... It may affect your result set...



  i hope this is enough, if not i can send all to you by mail.

It was enough to me...

Hope I could help... if no, don't hesitate to tell us..

Cheers,

Roger

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---