Re: [sqlalchemy] Custom UUID type with variant impl

2010-05-21 Thread Yang Zhang
On Thu, May 20, 2010 at 8:06 PM, Michael Bayer mike...@zzzcomputing.com wrote:

 On May 20, 2010, at 4:49 PM, Yang Zhang wrote:

 I defined a TypeDecorator with impl=postgres.PGUuid so that I can work
 with raw UUID bytes (instead of hex strings), but I'd like to make
 this portable to other DBMSs, where i want the impl to be a BLOB. How
 can I do this? The reference docs are pretty sparse here. Thanks in
 advance.

 i'd recommend a VARCHAR for a uuid as they are usually used as primary keys - 
 BLOBs make very poor primary keys.

But is there a way to accomplish this such that for PG dialects I'm
using a PGUuid instead of a CHAR?

-- 
Yang Zhang
http://yz.mit.edu/

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] could not assemble any primary key columns for mapped table '...'

2010-05-21 Thread Yang Zhang
On Thu, May 20, 2010 at 8:09 PM, Michael Bayer mike...@zzzcomputing.com wrote:

 On May 20, 2010, at 5:51 PM, Yang Zhang wrote:

 How do I create an ORM type with no primary key columns? For some
 reason I'm getting:

  sqlalchemy.exc.ArgumentError: Mapper
 Mapper|ActorActivity|actor_activities could not assemble any primary
 key columns for mapped table 'actor_activities'

 for:

 class ActorActivity(Base):
  __tablename__ = 'actor_activities'
  actor_id     =  Column(UUID,    ForeignKey(Actor.id),      nullable  =  
 False)
  t        =  Column(SmallInteger,  nullable = False)
  ts    =  Column(TIMESTAMP,     nullable = False)
  a  =  Column(UUID,    ForeignKey(A.id))
  b   =  Column(UUID,    ForeignKey(B.id))
  n   =  Column(SmallInteger)
  x  =  Column(SmallInteger)

 Thanks for any hints.


 the orm has to be given the list of columns that serve as the primary key 
 even if the table doesn't actually have any.  FAQ entry here:
 http://www.sqlalchemy.org/trac/wiki/FAQ#IhaveaschemawheremytabledoesnthaveaprimarykeycanSAsORMhandleit

I did see that, and the only thing I'll say here is: I know what I'm doing :)


 although here you can just put primary_key=True on those columns you'd like 
 to consider as PK cols, since you are using declarative and everything is in 
 one place anyway.

 if the issue is, you want no PK at all, even a python-only one, that's not 
 really possible.   The ORM needs a way to locate the row for your instance in 
 the DB in order to issue updates/deletes etc.

Thanks for the anwser.

It would be nice if this restriction could be lifted if explicitly
requested somehow (__use_pk__ = False, and have those operations raise
run-time exceptions if attempted). (As for why I'm using the ORM, it's
basically because it affords many relatively minor benefits such as
packaging up the tuple in its own object, a cleaner declaration syntax
than Table(...), no need to use table.c.blah, custom constructors and
methods, etc.)
--
Yang Zhang
http://yz.mit.edu/

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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: Do not bind None values in insert/update statements?

2010-05-21 Thread Tobias
Actually I am not manually constructing the insert statement,
SQLAlchemy is doing that for me. I am just committing my session:

spot_null = Spot(spot_height=None, spot_location=None)
session.add(spot_null)
session.commit();

Note that spot_location is a GeoAlchemy geometry column. And if the
value of this attribute is None, GeoAlchemy just returns None in its
bind_processor.process() method.

How is the type information sent to cx_Oracle. Using
Cursor.inputtypehandler (http://cx-oracle.sourceforge.net/html/
cursor.html#Cursor.inputtypehandler)?


On May 20, 7:04 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 On May 20, 2010, at 5:25 AM, Tobias wrote:



  Hi,

  I am working on Oracle support for GeoAlchemy and having problems when
  trying to insert NULL values into geometry columns.

  spot_null = Spot(spot_height=None, spot_location=None)
  session.add(spot_null)
  session.commit();

  DatabaseError: (DatabaseError) ORA-00932: inconsistent datatypes:
  expected MDSYS.SDO_GEOMETRY got CHAR
  'INSERT INTO spots (spot_id, spot_height, spot_location) VALUES
  (spots_id_seq.nextval, :spot_height, :spot_location) RETURNING
  spots.spot_id INTO :ret_0' {'spot_location': None, 'spot_height':
  None, 'ret_0': cx_Oracle.NUMBER with value None}

  The problem is that Oracle requires a type for bind parameters, and
  cx_Oracle -when using None- choses CHAR, because 'CHAR seems the most
  likely to cause the least difficulties', see [1]. I hope cx_Oracle
  will provide a proper way to use NULL for Oracle objects in near
  future.

  But right now I am wondering if there is still a way to insert NULL
  values into geometry columns. Does SQLAlchemy maybe have a column
  flag, so that the column is not used as bind parameter? Or something
  else?

  At the moment as workaround I set the attribute of my object to a
  select that queries NULL. It works but that is not a solution:

  spot_null = Spot(spot_height=None,
  spot_location=select([text('NULL')], from_obj=['dual']))

 bindparam() supports a type_ attribute, and we send cx_oracle typing 
 information for all binds except for strings (which for some reason seem to 
 make things work more poorly).   Not sure what the context here is though, 
 i.e. at what point are the bindparams being generated etc.

 if you really didn't want to bind them, then the insert() statement has to be 
 constructed that way.  I.e. it can't be execute(stmt, {'foo':None}), that's 
 too late in the process.

 need more context here.

 --
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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] multi Table FKs - ORM mapping

2010-05-21 Thread James Neethling
Hi All,

We're looking to add tags to a number of 'entities' within our
application. A simplified data structure would be:

Image:
id
file
title
description

Article:
id
text

Tag:
id
value


Entity_tags:
id
entity_type  ('image' or 'article'
entity_id(PK of the image/article table)
tag_id

We've got the following (highly simplified) structure:

image_table = Table('image', meta.metadata, 
Column('id', types.Integer, primary_key=True), ) 

article_table = Table('article', meta.metadata, 
Column('id', types.Integer, primary_key=True), ) 

tag_table = Table('tag', meta.metadata, 
Column('id', types.Integer, primary_key=True),
Column('name', types.Unicode(50), unique=True), ) 

entity_tag_table = Table('entity_tag', meta.metadata, 
Column('tag_id', types.Integer, ForeignKey(tag_table.c.id)),
Column('entity_type', types.String, nullable=False),
Column('entity_id', types.Integer, nullable=False),
) 

# And the ORM Mappings:

class Image(object): pass 
class Article(object): pass 
class Tag(object): pass 
class EntityTag(object): pass 

orm.mapper(Image, image_table, properties={ 
'tags': orm.relation(Tag, secondary=entity_tag_table,
primaryjoin=and_(image_table.c.id==EntityTag.entity_id,
EntityTag.entity_type=='image'),
secondaryjoin=EntityTag.tag_id==Tag.id,
foreignkeys=[EntityTag.entity_id, EntityTag.tag_id], ), 
}) 

orm.mapper(Article, article_table, properties={
'tags': orm.relation(Tag, secondary=entity_tag_table,
primaryjoin=and_(article_table.c.id==EntityTag.entity_id,
EntityTag.entity_type=='article'),
secondaryjoin=EntityTag.tag_id==Tag.id,
foreignkeys=[EntityTag.entity_id, EntityTag.tag_id], ), 
})


When we append to the image.tags collection, the entity_tag table needs
to know that the entity_type is 'image', but we can't seem to set that.

What is the standard way of dealing with this problem?

Is there the concept of a generic foreign key in SQLAlchemy?

Does anyone know if this database pattern has a formal name?

TIA,
Jim



-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] could not assemble any primary key columns for mapped table '...'

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 2:11 AM, Yang Zhang wrote:

 
 It would be nice if this restriction could be lifted if explicitly
 requested somehow (__use_pk__ = False, and have those operations raise
 run-time exceptions if attempted). (As for why I'm using the ORM, it's
 basically because it affords many relatively minor benefits such as
 packaging up the tuple in its own object, a cleaner declaration syntax
 than Table(...), no need to use table.c.blah, custom constructors and
 methods, etc.)

if you'd like to tell me what UPDATE statement should run during this operation:


my_object_with_no_pk = Session.query(MyClassWithNoPk).filter(...).one()

my_object_with_no_pk.some_attribute = 'new value'

Session.commit()

I'm all ears.




 --
 Yang Zhang
 http://yz.mit.edu/
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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: Do not bind None values in insert/update statements?

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 2:56 AM, Tobias wrote:

 Actually I am not manually constructing the insert statement,
 SQLAlchemy is doing that for me. I am just committing my session:
 
 spot_null = Spot(spot_height=None, spot_location=None)
 session.add(spot_null)
 session.commit();

a bindparam will be generated for spot_location, etc. and it will have the 
type_ of spot_location.   

If you want to hardwire some kind of SQL expression instead of NULL, assign it 
to your mapped object:

Spot(spot_location=text('some_null_token'))

the commit will embed that in the INSERT.


 
 Note that spot_location is a GeoAlchemy geometry column. And if the
 value of this attribute is None, GeoAlchemy just returns None in its
 bind_processor.process() method.
 
 How is the type information sent to cx_Oracle. Using
 Cursor.inputtypehandler (http://cx-oracle.sourceforge.net/html/
 cursor.html#Cursor.inputtypehandler)?
 
 
 On May 20, 7:04 pm, Michael Bayer mike...@zzzcomputing.com wrote:
 On May 20, 2010, at 5:25 AM, Tobias wrote:
 
 
 
 Hi,
 
 I am working on Oracle support for GeoAlchemy and having problems when
 trying to insert NULL values into geometry columns.
 
 spot_null = Spot(spot_height=None, spot_location=None)
 session.add(spot_null)
 session.commit();
 
 DatabaseError: (DatabaseError) ORA-00932: inconsistent datatypes:
 expected MDSYS.SDO_GEOMETRY got CHAR
 'INSERT INTO spots (spot_id, spot_height, spot_location) VALUES
 (spots_id_seq.nextval, :spot_height, :spot_location) RETURNING
 spots.spot_id INTO :ret_0' {'spot_location': None, 'spot_height':
 None, 'ret_0': cx_Oracle.NUMBER with value None}
 
 The problem is that Oracle requires a type for bind parameters, and
 cx_Oracle -when using None- choses CHAR, because 'CHAR seems the most
 likely to cause the least difficulties', see [1]. I hope cx_Oracle
 will provide a proper way to use NULL for Oracle objects in near
 future.
 
 But right now I am wondering if there is still a way to insert NULL
 values into geometry columns. Does SQLAlchemy maybe have a column
 flag, so that the column is not used as bind parameter? Or something
 else?
 
 At the moment as workaround I set the attribute of my object to a
 select that queries NULL. It works but that is not a solution:
 
 spot_null = Spot(spot_height=None,
 spot_location=select([text('NULL')], from_obj=['dual']))
 
 bindparam() supports a type_ attribute, and we send cx_oracle typing 
 information for all binds except for strings (which for some reason seem to 
 make things work more poorly).   Not sure what the context here is though, 
 i.e. at what point are the bindparams being generated etc.
 
 if you really didn't want to bind them, then the insert() statement has to 
 be constructed that way.  I.e. it can't be execute(stmt, {'foo':None}), 
 that's too late in the process.
 
 need more context here.
 
 --
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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 sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Manlio Perillo
Hi.

In a project using SQLAlchemy I decided to use the SQL nose plugin, in
order to avoid reinventing the wheel.

Unfortunately it seems the plugin is a bit too invasive and it will only
work with SQLAlchemy test suite.

The problem is with the wantClass method, that pratically will ignore
all normal test cases.

Fortunately, in my case I use an additional nose plugin:
http://bitbucket.org/mperillo/nose-tree

and increasing its score solved the problem.


Is is possible to modify the SQLAlchemy nose plugin in order to be more
cooperative?
As an example by adding an option that will change the wantClass method from

  if not issubclass(cls, testing.TestBase):
  return False
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)

to something like (not tested):

  if self.sa_only and not issubclass(cls, testing.TestBase):
  return False

  if issubclass(cls, testing.TestBase):
  if (hasattr(cls, '__whitelist__') and testing.db.name in
cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)

  # use nose default



Thanks  Manlio

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] multi Table FKs - ORM mapping

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 5:08 AM, James Neethling wrote:

 Hi All,
 
 
 When we append to the image.tags collection, the entity_tag table needs
 to know that the entity_type is 'image', but we can't seem to set that.
 
 What is the standard way of dealing with this problem?
 
 Is there the concept of a generic foreign key in SQLAlchemy?
 
 Does anyone know if this database pattern has a formal name?


it is often called polymorhpic association and there is a full series of 
examples in examples/poly_assoc, as well as a link to a blog post regarding the 
subject in the __init__.py file.


-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] could not assemble any primary key columns for mapped table '...'

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 9:12 AM, Michael Bayer wrote:

 
 On May 21, 2010, at 2:11 AM, Yang Zhang wrote:
 
 
 It would be nice if this restriction could be lifted if explicitly
 requested somehow (__use_pk__ = False, and have those operations raise
 run-time exceptions if attempted). (As for why I'm using the ORM, it's
 basically because it affords many relatively minor benefits such as
 packaging up the tuple in its own object, a cleaner declaration syntax
 than Table(...), no need to use table.c.blah, custom constructors and
 methods, etc.)
 
 if you'd like to tell me what UPDATE statement should run during this 
 operation:
 
 
 my_object_with_no_pk = Session.query(MyClassWithNoPk).filter(...).one()
 
 my_object_with_no_pk.some_attribute = 'new value'
 
 Session.commit()
 
 I'm all ears.

additionally, if you'd argue that such an operation would simply be not 
allowed, it still brings us no closer to determining how the identity map would 
function here.The ORM is archtected around an identity map model.The 
identity map is not just a cache, its real purpose is so that objects 
associated with a session are unique relative to the row they represent in the 
database.

I think here you really mean to be using the SQL expression language directly, 
since if your row has no primary key you really won't get any benefit from the 
ORM in any case.


-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 9:15 AM, Manlio Perillo wrote:

 Hi.
 
 In a project using SQLAlchemy I decided to use the SQL nose plugin, in
 order to avoid reinventing the wheel.
 
 Unfortunately it seems the plugin is a bit too invasive and it will only
 work with SQLAlchemy test suite.
 
 The problem is with the wantClass method, that pratically will ignore
 all normal test cases.
 
 Fortunately, in my case I use an additional nose plugin:
 http://bitbucket.org/mperillo/nose-tree
 
 and increasing its score solved the problem.



 
 
 Is is possible to modify the SQLAlchemy nose plugin in order to be more
 cooperative?
 As an example by adding an option that will change the wantClass method from
 
  if not issubclass(cls, testing.TestBase):
  return False
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)
 
 to something like (not tested):
 
  if self.sa_only and not issubclass(cls, testing.TestBase):
  return False
 
  if issubclass(cls, testing.TestBase):
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)
 
  # use nose default

whats sa_only and how does that get set ?  it seems like the score 
attribute is already provided by Nose for the purpose of setting plugin 
priority ?  (since you are already setting attributes on plugins, it seems)


-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] could not assemble any primary key columns for mapped table '...'

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 9:21 AM, Michael Bayer wrote:

 
 On May 21, 2010, at 9:12 AM, Michael Bayer wrote:
 
 
 On May 21, 2010, at 2:11 AM, Yang Zhang wrote:
 
 
 It would be nice if this restriction could be lifted if explicitly
 requested somehow (__use_pk__ = False, and have those operations raise
 run-time exceptions if attempted). (As for why I'm using the ORM, it's
 basically because it affords many relatively minor benefits such as
 packaging up the tuple in its own object, a cleaner declaration syntax
 than Table(...), no need to use table.c.blah, custom constructors and
 methods, etc.)
 
 if you'd like to tell me what UPDATE statement should run during this 
 operation:
 
 
 my_object_with_no_pk = Session.query(MyClassWithNoPk).filter(...).one()
 
 my_object_with_no_pk.some_attribute = 'new value'
 
 Session.commit()
 
 I'm all ears.
 
 additionally, if you'd argue that such an operation would simply be not 
 allowed, it still brings us no closer to determining how the identity map 
 would function here.The ORM is archtected around an identity map model.   
  The identity map is not just a cache, its real purpose is so that objects 
 associated with a session are unique relative to the row they represent in 
 the database.
 
 I think here you really mean to be using the SQL expression language 
 directly, since if your row has no primary key you really won't get any 
 benefit from the ORM in any case.

Also the other features you mention like using objects to represent rows are 
pretty trivial to re-implement.   The declarative system you like is all part 
of ext.declarative and follows a common metaclass model that I use for all 
kinds of non-ORM tasks.  Table.c.blah can be avoided by just passing c 
around, but even better just implement them as descriptors on your classes - 
just follow the example of sqlalchemy.orm.attributes.QueryableAttribute, 
subclass expression.ColumnOperators and implement __clause_element__(), 
operate(), and reverse_operate().   The rows that come back from a result do 
allow attribute acccess, like row.bar, but you'd wrap around 
connection.execute() to return your instrumented objects in any case.

It was always intended that users would create their own micro-ORMs for those 
cases where the decidedly opinionated approach of the SQLA ORM is not 
appropriate.   This is one reason the SQL expression system is so prominent.



-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] joinedload alias

2010-05-21 Thread jose soares

Hi all,

I'm trying to use joinedload('specie') in a query but it makes an 
unexpected alias of table name to 'specie_1' and it conflict with passed 
orderby column specie.descrizione, as in:



ProgrammingError: ('(ProgrammingError) invalid reference to FROM-clause 
entry for table specie\nLINE 2: ..._1 ON specie_1.codice = 
razza.cod_specie ORDER BY specie.des...\n ^\nHINT: Perhaps you meant to 
reference the table alias specie_1.\n', bound method Controller.index 
of sicer.BASE.controller.tabelleCodifica.razza.Controller object at 
0x72cc1d0) 'SELECT razza.codice AS razza_codice, razza.descrizione AS 
razza_descrizione, razza.cod_specie AS razza_cod_specie, specie_1.codice 
AS specie_1_codice, specie_1.descrizione AS specie_1_descrizione, 
specie_1.cod_gruppo_specie AS specie_1_cod_gruppo_specie, 
specie_1.categoria_prodotto AS specie_1_categoria_prodotto \nFROM razza 
LEFT OUTER JOIN specie AS specie_1 ON specie_1.codice = razza.cod_specie 
ORDER BY specie.descrizione ASC, razza.descrizione ASC \n LIMIT 12 
OFFSET 0' {}


Is there a way to tell joinedload to not make the alias or a way to pass 
it the alias name?


thank you.

j

--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] joinedload alias

2010-05-21 Thread Michael Bayer
this looks like:

http://www.sqlalchemy.org/trac/wiki/FAQ#ImusinglazyFalsetocreateaJOINOUTERJOINandSQLAlchemyisnotconstructingthequerywhenItrytoaddaWHEREORDERBYLIMITetc.whichreliesupontheOUTERJOIN




On May 21, 2010, at 9:56 AM, jose soares wrote:

 Hi all,
 
 I'm trying to use joinedload('specie') in a query but it makes an unexpected 
 alias of table name to 'specie_1' and it conflict with passed orderby column 
 specie.descrizione, as in:
 
 
 ProgrammingError: ('(ProgrammingError) invalid reference to FROM-clause entry 
 for table specie\nLINE 2: ..._1 ON specie_1.codice = razza.cod_specie ORDER 
 BY specie.des...\n ^\nHINT: Perhaps you meant to reference the table alias 
 specie_1.\n', bound method Controller.index of 
 sicer.BASE.controller.tabelleCodifica.razza.Controller object at 
 0x72cc1d0) 'SELECT razza.codice AS razza_codice, razza.descrizione AS 
 razza_descrizione, razza.cod_specie AS razza_cod_specie, specie_1.codice AS 
 specie_1_codice, specie_1.descrizione AS specie_1_descrizione, 
 specie_1.cod_gruppo_specie AS specie_1_cod_gruppo_specie, 
 specie_1.categoria_prodotto AS specie_1_categoria_prodotto \nFROM razza LEFT 
 OUTER JOIN specie AS specie_1 ON specie_1.codice = razza.cod_specie ORDER BY 
 specie.descrizione ASC, razza.descrizione ASC \n LIMIT 12 OFFSET 0' {}
 
 Is there a way to tell joinedload to not make the alias or a way to pass it 
 the alias name?
 
 thank you.
 
 j
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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: Alembic

2010-05-21 Thread Chris Withers

Michael Bayer wrote:

It's not clear that Alembic has real advantages over Migrate.  Its
simpler for sure since it only is for SQLA 0.6 and up and doesn't
attempt to do the crazy things Migrate does like versioning SQLite
databases.  I'm going to attempt to handle branching (but already
that means, ugly hex digest version numbers).  


I'm glad that handling branching is something I don't even want to ever 
contemplate ;-)

(which undoubtably means I'll need to do it next week!)
To clarify; Alembic supports branching, Migrate doesn't?
(and where can I find out exactly what is meant by branching?)


 It also doesn't have any of the schema comparison stuff Migrate
has, which seems to be the kind of thing people want (Ken's request
is not the first I've heard).  Migrate could improve a lot on that
feature if they use the new Inspector interface in 0.6.


Would you be interested in patches that added this kind of functionality 
to Alembic using the new Inspector interface?


cheers,

Chris

--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Bayer ha scritto:
 [...]

 Is is possible to modify the SQLAlchemy nose plugin in order to be more
 cooperative?
 As an example by adding an option that will change the wantClass method from

  if not issubclass(cls, testing.TestBase):
  return False
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)

 to something like (not tested):

  if self.sa_only and not issubclass(cls, testing.TestBase):
  return False

  if issubclass(cls, testing.TestBase):
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)

  # use nose default
 
 whats sa_only and how does that get set ?

It is a boolean value, and it is set from a nose config option, defined
in the SQLAlchemy plugin.

  it seems like the score attribute is already provided by Nose for the 
 purpose of setting plugin priority ?  (since you are already setting 
 attributes on plugins, it seems)
 

The problem is that if I don't use my plugin (with a score higher than
the one of the SQLAlchemy plugin), the wantMethod from SQLAlchemy plugin
will be used, thus ignoring all normal tests cases (that is, test
cases not derived from sqlalchemy.testing.TestBase).



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv2lWEACgkQscQJ24LbaUTzxwCeOcCmfNOAhGgLNjlaM6YLvDxc
sp0AmQFC0OXr/KLeHlJpg7hwZ9MieOEk
=/PGv
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Bayer ha scritto:
 [...]
 Is is possible to modify the SQLAlchemy nose plugin in order to be more
 cooperative?
 As an example by adding an option that will change the wantClass method from

  if not issubclass(cls, testing.TestBase):
  return False
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)

 to something like (not tested):

  if self.sa_only and not issubclass(cls, testing.TestBase):
  return False

  if issubclass(cls, testing.TestBase):
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)

  # use nose default
 

A precisation.

The reason I used the sa_only flag is because I assumed there was a
reason why test cases not derived from testing.TestBase must be ignored.

If possible, the wantMethod should be something like:

  if not issubclass(cls, testing.TestBase):
  # Skip
  return None
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)


Another problem I found when using SQLAlchemy nose plugin is that
warnings are configured to raise exceptions, and this is a problem for me.


By the way: what is the reason why testing.Test does not derive from
unittest.TestCase?

I would like to use __unsupported_on__, but with current implementation
it is a pain (and there is also the problem with how nose plugins work,
since SQLAlchemy wantClass method will be ignored in case another plugin
with an higher score is available).



Thanks  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv2n4AACgkQscQJ24LbaURU4gCfeVQRuEOTHpQb9hzCoA0aEfB/
6RsAoJn9L51KObvWva7WOQIY21dpYDCf
=ZI6r
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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: Alembic

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 10:13 AM, Chris Withers wrote:

 Michael Bayer wrote:
 It's not clear that Alembic has real advantages over Migrate.  Its
 simpler for sure since it only is for SQLA 0.6 and up and doesn't
 attempt to do the crazy things Migrate does like versioning SQLite
 databases.  I'm going to attempt to handle branching (but already
 that means, ugly hex digest version numbers).  
 
 I'm glad that handling branching is something I don't even want to ever 
 contemplate ;-)
 (which undoubtably means I'll need to do it next week!)
 To clarify; Alembic supports branching, Migrate doesn't?
 (and where can I find out exactly what is meant by branching?)

it means if you have a branch of the repo, so say you start with source A with 
versions:


1
2
3

then you branch into B.   A continues to get more versions:

4
5
6

B also gets more versions:

4
5
6
7


so now you want to merge B back to A.   because migrate is counting with 
integers, you're out of luck.  You have to renumber your files somehow so that 
they all work out.

What I'm doing, you still might have an uphill battle if A and B have 
non-compatible migrations, but we're using randomly generated hex ids:

a65fe
47aed
277eef

and the ordering of versions is done using a link from one version to the 
previous, which is literally just a variable inside the file   
previous_version = '47aed'.So you can merge two branches together, and 
there will be a command that modifies the previous_version identifier for you 
so that it does a splice.  it will also add a mediating version in between 
them in case something needs to be done to bring B into A.

its still kind of confusing but is more along the way.



 
 It also doesn't have any of the schema comparison stuff Migrate
 has, which seems to be the kind of thing people want (Ken's request
 is not the first I've heard).  Migrate could improve a lot on that
 feature if they use the new Inspector interface in 0.6.
 
 Would you be interested in patches that added this kind of functionality to 
 Alembic using the new Inspector interface?

yes, but I'd rather you keep working on declarative Mixin issues :)   (there's 
more in trac).


-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 10:58 AM, Manlio Perillo wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Michael Bayer ha scritto:
 [...]
 Is is possible to modify the SQLAlchemy nose plugin in order to be more
 cooperative?
 As an example by adding an option that will change the wantClass method from
 
 if not issubclass(cls, testing.TestBase):
 return False
 else:
 if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
 return True
 else:
 return not self.__should_skip_for(cls)
 
 to something like (not tested):
 
 if self.sa_only and not issubclass(cls, testing.TestBase):
 return False
 
 if issubclass(cls, testing.TestBase):
 if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
 return True
 else:
 return not self.__should_skip_for(cls)
 
 # use nose default
 
 
 A precisation.
 
 The reason I used the sa_only flag is because I assumed there was a
 reason why test cases not derived from testing.TestBase must be ignored.
 
 If possible, the wantMethod should be something like:
 
  if not issubclass(cls, testing.TestBase):
  # Skip
  return None
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)
 
 
 Another problem I found when using SQLAlchemy nose plugin is that
 warnings are configured to raise exceptions, and this is a problem for me.

OK my thought here is that yeah, this is likely a problem for you, but the nose 
plugin currently is not implemented in such a way as to be usable for other 
people's test configurations. It might be nice for it to be used this way 
but that's not on the current roadmap and could have all kinds of inconvenient 
issues where nose doesn't quite give us enough flexibility to give SQLA what it 
needs while also being completely useable by other projects.   I don't even 
like everything that the nose plugin does right now and I'd like to change it a 
lot further, the way it gets database URLs, the way it runs through multiple 
databases for tests, the way the plugin gets loaded.All of which would 
break any end user approach that has built upon it directly.   So I'm not 
entirely comfortable with users buliding their external non-SQLA test suites on 
top of it.

Whereas just copying the parts of it you need for your own purposes is a way to 
get what you need - I dont use the Nose plugin directly outside of SQLA myself, 
I do exactly this.

 
 
 By the way: what is the reason why testing.Test does not derive from
 unittest.TestCase?

nose doesn't require unittest.   Ideally we would be able to run tests that 
don't derive from any class at all.I don't usually use a base class for 
tests, its a historical artifact of the fact that SQLA was written against 
unittest originally.   If I were starting over with nose, I'd do things very 
differently.   Since nose has taken a deep dive into the its author can't 
support it anymore category, I'm waiting for the next de-facto test library 
(nose2 i think it was called ?) comes out before doing another full refactor of 
the tests, but I'd like it to be nose-like and not unittest-like.





-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] Custom UUID type with variant impl

2010-05-21 Thread Yang Zhang
Thanks for your follow-up answers to my questions (and in the other
thread). I am curious about what you said on BLOBs making for poor
PKs. Can you elaborate on that and/or point me to something that does?
Thanks in advance.

On Thu, May 20, 2010 at 8:06 PM, Michael Bayer mike...@zzzcomputing.com wrote:

 On May 20, 2010, at 4:49 PM, Yang Zhang wrote:

 I defined a TypeDecorator with impl=postgres.PGUuid so that I can work
 with raw UUID bytes (instead of hex strings), but I'd like to make
 this portable to other DBMSs, where i want the impl to be a BLOB. How
 can I do this? The reference docs are pretty sparse here. Thanks in
 advance.

 i'd recommend a VARCHAR for a uuid as they are usually used as primary keys - 
 BLOBs make very poor primary keys.

 impl is like:

 class GUIDType(TypeDecorator):
    impl = sa.CHAR

    def __init__(self):
        TypeDecorator.__init__(self, length=16)

    def load_dialect_impl(self, dialect):
        if dialect.name == 'sqlite':
            return dialect.type_descriptor(sa.CHAR(self.impl.length))
        else:
            return dialect.type_descriptor(pg.UUID())

    def process_bind_param(self, value, dialect):
        if value is None:
            return value
        else:
            return str(value)

    def process_result_value(self, value, dialect):
        if value is None:
            return value
        else:
            return uuid.UUID(value)




 --
 Yang Zhang
 http://yz.mit.edu/

 --
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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.





-- 
Yang Zhang
http://yz.mit.edu/

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] Custom UUID type with variant impl

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 2:09 PM, Yang Zhang wrote:

 Thanks for your follow-up answers to my questions (and in the other
 thread). I am curious about what you said on BLOBs making for poor
 PKs. Can you elaborate on that and/or point me to something that does?
 Thanks in advance.

BLOBs are optimized for very large, arbitrary size and are not well chosen for 
indexing nor for storing a fixed length binary string.   Databases like Oracle 
explicitly disallow placing indexes on BLOB columns.You should choose a 
fixed-size type like CHAR, BINARY, etc. or whatever the database provides that 
is closest and also allows indexing (since GUIDs are usually used for lookups).



 
 On Thu, May 20, 2010 at 8:06 PM, Michael Bayer mike...@zzzcomputing.com 
 wrote:
 
 On May 20, 2010, at 4:49 PM, Yang Zhang wrote:
 
 I defined a TypeDecorator with impl=postgres.PGUuid so that I can work
 with raw UUID bytes (instead of hex strings), but I'd like to make
 this portable to other DBMSs, where i want the impl to be a BLOB. How
 can I do this? The reference docs are pretty sparse here. Thanks in
 advance.
 
 i'd recommend a VARCHAR for a uuid as they are usually used as primary keys 
 - BLOBs make very poor primary keys.
 
 impl is like:
 
 class GUIDType(TypeDecorator):
impl = sa.CHAR
 
def __init__(self):
TypeDecorator.__init__(self, length=16)
 
def load_dialect_impl(self, dialect):
if dialect.name == 'sqlite':
return dialect.type_descriptor(sa.CHAR(self.impl.length))
else:
return dialect.type_descriptor(pg.UUID())
 
def process_bind_param(self, value, dialect):
if value is None:
return value
else:
return str(value)
 
def process_result_value(self, value, dialect):
if value is None:
return value
else:
return uuid.UUID(value)
 
 
 
 
 --
 Yang Zhang
 http://yz.mit.edu/
 
 --
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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.
 
 
 
 
 
 -- 
 Yang Zhang
 http://yz.mit.edu/
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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: Alembic

2010-05-21 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Bayer ha scritto:
 [...]
 To clarify; Alembic supports branching, Migrate doesn't?
 (and where can I find out exactly what is meant by branching?)
 
 it means if you have a branch of the repo, so say you start with source A 
 with versions:
 
 
 1
 2
 3
 
 then you branch into B.   A continues to get more versions:
 
 4
 5
 6
 
 B also gets more versions:
 
 4
 5
 6
 7
 
 
 so now you want to merge B back to A.   because migrate is counting with 
 integers, you're out of luck.  You have to renumber your files somehow so 
 that they all work out.
 
 What I'm doing, you still might have an uphill battle if A and B have 
 non-compatible migrations, but we're using randomly generated hex ids:
 
 a65fe
 47aed
 277eef
 

What about using revisions strings, as handled by setuptools?

You have version 0.1 and 0.2, and branches 0.1.1, 0.1.1, and 0.2.1, 0.2.2.

So, versions have a well defined ordering.

However I'm still not sure what a merge should do.

 [...]


Regards   Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv20zYACgkQscQJ24LbaUTJ+QCgj9HjEjacyjAYflPu74DaSZrN
Cg0An0dwxCMpSZucpayt4zMvnyN44bTv
=vIGO
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Manlio Perillo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Bayer ha scritto:
 [...]
 A precisation.

 The reason I used the sa_only flag is because I assumed there was a
 reason why test cases not derived from testing.TestBase must be ignored.

 If possible, the wantMethod should be something like:

  if not issubclass(cls, testing.TestBase):
  # Skip
  return None
  else:
  if (hasattr(cls, '__whitelist__') and testing.db.name in
 cls.__whitelist__):
  return True
  else:
  return not self.__should_skip_for(cls)


 Another problem I found when using SQLAlchemy nose plugin is that
 warnings are configured to raise exceptions, and this is a problem for me.
 
 OK my thought here is that yeah, this is likely a problem for you,

Right now, fortunately, I have solved all the problems.

And the only thing I use from SQLA plugin is testing.db, so that I don't
have to hard write the database to use.

I would like to use support for skipping test for specified dialects,
but it is not a big issue (and given the way nose plugins work, I can
not use the SQLA plugin implementation).


 [...]

 By the way: what is the reason why testing.Test does not derive from
 unittest.TestCase?
 
 nose doesn't require unittest.   Ideally we would be able to run tests that 
 don't derive from any class at all. 


I have a bad experience with this, using nose.

In my code I use functions like setup_testing_defaults, and by default
nose try to execute it as a test.

The first time I used nose, I got several failure and I took some time
to understand what was going on.

I had to write a custom plugin, to change this.

Another advantace of using UnitTest classes, is that test execution can
be pretty printed in a tree (I liked the output produced by
twisted.trial, and I have tried to reproduce it for nose).

 [...]
 Since nose has taken a deep dive into the its author can't support it 
 anymore category,

I was not aware of nose state.

 I'm waiting for the next de-facto test library (nose2 i think it was called 
 ?) 

If I remember correctly there is an unittest2 project for the standard
library.



Regards  Manlio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkv21a8ACgkQscQJ24LbaURjuQCeO1GG8kXxUwOODIEtkZxe+AW3
ZtMAn14kktUZOpa5ar0tkZbXwAjM13I0
=Sny0
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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] reusing the SQLAlchemy nose plugin

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 2:49 PM, Manlio Perillo wrote:
 
 [...]
 Since nose has taken a deep dive into the its author can't support it 
 anymore category,
 
 I was not aware of nose state.
 
 I'm waiting for the next de-facto test library (nose2 i think it was called 
 ?) 
 
 If I remember correctly there is an unittest2 project for the standard
 library.

nose2 is the nose for unittest2.

https://bitbucket.org/jpellerin/nose2/wiki/Home



 
 
 
 Regards  Manlio
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iEYEARECAAYFAkv21a8ACgkQscQJ24LbaURjuQCeO1GG8kXxUwOODIEtkZxe+AW3
 ZtMAn14kktUZOpa5ar0tkZbXwAjM13I0
 =Sny0
 -END PGP SIGNATURE-
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@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 sqlalch...@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] BLOB and str comparisons

2010-05-21 Thread Yang Zhang
I'm trying to run the following:

  session.query(Activity).filter(Activity.blob == blob).one()

where Activity.blob is a BLOB and blob is a Python bytes object
(equiv. to str in Python 2.x). But although I can insert Activity(blob
= blob) objects fine, the above query fails with:

ProgrammingError: (ProgrammingError) You must not use 8-bit
bytestrings unless you use a text_factory that can interpret 8-bit
bytestrings (like text_factory = str).

This is because blob has to be wrapped with sqlite3.Binary(blob). Why
doesn't sqlalchemy automatically do this casting, given that it has
schema awareness? Is there any way to avoid having to do this for
every such query?

Thanks in advance.
--
Yang Zhang
http://yz.mit.edu/

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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: BLOB and str comparisons

2010-05-21 Thread Yang Zhang
On Fri, May 21, 2010 at 6:47 PM, Yang Zhang yanghates...@gmail.com wrote:
 I'm trying to run the following:

  session.query(Activity).filter(Activity.blob == blob).one()

 where Activity.blob is a BLOB and blob is a Python bytes object
 (equiv. to str in Python 2.x). But although I can insert Activity(blob
 = blob) objects fine, the above query fails with:

 ProgrammingError: (ProgrammingError) You must not use 8-bit
 bytestrings unless you use a text_factory that can interpret 8-bit
 bytestrings (like text_factory = str).

 This is because blob has to be wrapped with sqlite3.Binary(blob). Why
 doesn't sqlalchemy automatically do this casting, given that it has
 schema awareness? Is there any way to avoid having to do this for
 every such query?

 Thanks in advance.
 --
 Yang Zhang
 http://yz.mit.edu/



Also, how do I do the wrapping portably? For sqlite3 I have to wrap
with sqlite3.Binary, for postgresql I have to wrap with
psycopg2.Binary, etc.


-- 
Yang Zhang
http://yz.mit.edu/

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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: BLOB and str comparisons

2010-05-21 Thread Michael Bayer

On May 21, 2010, at 10:04 PM, Yang Zhang wrote:

 On Fri, May 21, 2010 at 6:47 PM, Yang Zhang yanghates...@gmail.com wrote:
 I'm trying to run the following:
 
  session.query(Activity).filter(Activity.blob == blob).one()
 
 where Activity.blob is a BLOB and blob is a Python bytes object
 (equiv. to str in Python 2.x). But although I can insert Activity(blob
 = blob) objects fine, the above query fails with:
 
 ProgrammingError: (ProgrammingError) You must not use 8-bit
 bytestrings unless you use a text_factory that can interpret 8-bit
 bytestrings (like text_factory = str).
 
 This is because blob has to be wrapped with sqlite3.Binary(blob). Why
 doesn't sqlalchemy automatically do this casting, given that it has
 schema awareness? Is there any way to avoid having to do this for
 every such query?
 
 Thanks in advance.
 --
 Yang Zhang
 http://yz.mit.edu/
 
 
 
 Also, how do I do the wrapping portably? For sqlite3 I have to wrap
 with sqlite3.Binary, for postgresql I have to wrap with
 psycopg2.Binary, etc.

the SQLAlchemy LargeBinary type and subclasses handle the dbapi.Binary wrapping 
for you.   In the case of your comparison, you might want to say 
literal(mydata, type_=LargeBinary), if LargeBinary is in fact not being pulled 
in and is actually the cause of that error, however this should not be 
necessary - in Python 3, the bytes type is detected and is coerced into 
LargeBinary when passed as a value (you can see this on line 1798 of 
sqlalchemy/types.py). I am not able to reproduce your error in py2k or py3k:

from sqlalchemy import *

engine = create_engine('sqlite://', echo=True)

m = MetaData()
t = Table('t', m, Column('data', LargeBinary))

m.create_all(engine)

engine.execute(t.insert(), {'data':b'abc'}, {'data':b'xyz'})
engine.execute(t.select().where(t.c.data==b'xyz'))

output:

200:sqlalchemy classic$ python3.1 test.py 
2010-05-22 01:12:35,595 INFO sqlalchemy.engine.base.Engine.0x...27b0 PRAGMA 
table_info(t)
2010-05-22 01:12:35,597 INFO sqlalchemy.engine.base.Engine.0x...27b0 ()
2010-05-22 01:12:35,598 INFO sqlalchemy.engine.base.Engine.0x...27b0 
CREATE TABLE t (
data BLOB
)


2010-05-22 01:12:35,598 INFO sqlalchemy.engine.base.Engine.0x...27b0 ()
2010-05-22 01:12:35,598 INFO sqlalchemy.engine.base.Engine.0x...27b0 COMMIT
2010-05-22 01:12:35,598 INFO sqlalchemy.engine.base.Engine.0x...27b0 INSERT 
INTO t (data) VALUES (?)
2010-05-22 01:12:35,599 INFO sqlalchemy.engine.base.Engine.0x...27b0 ((memory 
at 0x12a1850,), (memory at 0x12a18a0,))
2010-05-22 01:12:35,599 INFO sqlalchemy.engine.base.Engine.0x...27b0 COMMIT
2010-05-22 01:12:35,599 INFO sqlalchemy.engine.base.Engine.0x...27b0 SELECT 
t.data 
FROM t 
WHERE t.data = ?
2010-05-22 01:12:35,599 INFO sqlalchemy.engine.base.Engine.0x...27b0 (memory 
at 0x12a1850,)




-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@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.