[sqlalchemy] Re: Consistency with DB while modifying metadata
t = Table('mytable', meta,
Column(...)
)
someothermeta = MetaData()
t2 = Table('mytable', someothermetadata, autoload=True,
autoload_with=connection)
assert t.compare(t2)
I believe this should be done somehow automatically. Because everyone
needs this. There should be two separate disjoint options:
1) Autoload, when working with previously created database for rapid
start. Columns arent specified at all in Python code (SQLAlchemy).
2) Tables are specified in the code. Database tables might already
exist and might not. And when issuing create_all(), all the situations
should be handled correctly:
2a) If tables exist in DB and match Python-defined, ok.
2b) If tables do not exist in DB they are created, ok.
2c) If tables exist in DB and there is mismatch with Python-defined,
an exception is raised.
If feel this is kind of natural. Though, I am not an expert in DB or
SQLAlchemy.
but why not just use autoload=True across the board in the first
place and eliminate the chance of any errors ?
1) I dont know if tables exist. I might need to create them.
2) When they exist, autoloading them might cause inconsistency with
SQLAlchemy-defined tables in sources. This is exactly what I am trying
to avoid.
--~--~-~--~~~---~--~~
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: How to use SessionContextExt with cherrypy?
Thanks again for you enlightening answer.
I had no understanding for these different scopes.
What I haven't managed is to call a db function from a session/query
object.
I had the following line in my code, but it doesn't work anymore.
select([func.max(table.c.DocID)]).execute().scalar()
How would I call the max function having a query or session object, as
in the example below?
Thanks again!
from sqlalchemy import *
metadata = MetaData()
docs = Table('docs', metadata)
docs.append_column(Column('DocID', Integer, primary_key=True))
docs.append_column(Column('Path', String(120)))
docs.append_column(Column('Complete', Boolean))
class Doc(object):
def __init__(self, id, path, state):
self.DocID = id
self.Path = path
self.Complete = state
def __str__(self):
return '(%s) %s %s' %(self.DocID, self.Path, self.Complete)
if __name__ == __main__:
mapper(Doc, docs)
db = create_engine( 'sqlite:///mydb' )
db.echo = False
s = create_session(bind_to = db)
q = s.query(Doc)
On Jul 24, 6:36 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 24, 2007, at 12:09 PM, alex.schenkman wrote:
class Session(object):
def __init__(self, name):
self.db = create_engine( 'sqlite:///%s' % name )
self.db.echo = False
self.metadata = BoundMetaData(self.db)
self.session = create_session()
self.db.docs = Table('docs', self.metadata, autoload=True)
self.db.mapper = mapper(Document, self.myDB.docs)
mappers are at the same level at which your mapped class is defined.
So if you define your Document class at the module level, so must
your Mapper be defined. also, if you defined classes and mappers
within a function for each session, that wouldnt scale anyway since
the mappers get stored in a global registry and youd run out of
memory after many distinct users visited the site.
so if your mapper is at the module level, so are your Tables and
MetaData. Sessions are not; so bind your individual sessions to the
engines directly. (Engines are usually module level too, but in this
case you are opening many individual sqlite files so theyre local to
your Session object)
metadata = MetaData()
class Document(object):
pass
# cant autoload=True here unless you have a specific SQLite file that
is safe to use. doesnt your
# system need to create the tables inside the sqlite databases anyway ?
docs = Table('docs', metadata,
Column(...)
)
mapper(Document, docs)
class Session(object):
def __init__(self, name):
self.db = create_engine('sqlite:///%s' % name)
self.session = create_session(bind = self.db)
thats it. you dont need to reference mapper anywhere, just
self.session and maybe docs.
--~--~-~--~~~---~--~~
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] UnicodeDecodeError: 'utf8' codec can't decode bytes in position 94-96: invalid data
Guys, I am getting this error on reading data from a MySQL table. I have specified the charset of the table as utf-8 and collation utf8_general_ci. Do I need to do anything else ? Will *convert_unicode=True help? * -- Cheers, - A --~--~-~--~~~---~--~~ 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] autoload'ing metadata
this is along the recent threads about metadata consistency between code and DB, and the DB-migration. Both these require a full metadata reflection from database. Here a version of autocode.py, hacked for couple of hours. It has more systematic approach, replaces back column types with SA ones, has sqlite and postgress, and is somewhat simpler but more dense. Output also looks nicer (nested identation). Not tested for mssql. my idea is to use this metadata-reflection as starting point towards model-migration technology or framework or whatever. one way is to put all metadata-reflection in the dialects themselves. Maybe there should be reflect_metadata() method, which will extract all tables/names, indexes, etc. This is what i like, although it means hacking 10 files instead of one. But it would be more easier/consistent on the long run. Another way is to pull all reflection stuff out of dialects, or at least separate it somehow. anyway. http://www.sqlalchemy.org/trac/wiki/UsageRecipes/AutoCode#autoload2codeorAutoCode3 using some metadata howto from: http://sqlzoo.cn/howto/source/z.dir/tip137084/i12meta.xml --~--~-~--~~~---~--~~ 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] Choosing a few columns out a query object
Hello: How do I get only a few columns from a query object? q = session.query(Document).select_by(Complete=False) would give me a list of rows (all columns) where Complete == False. I have seen the select([doc.c.name]) notation but it doesn't work for me. select([docs.c.DocID]).execute() Gives me: sqlalchemy.exceptions.InvalidRequestError: This Compiled object is not bound to any engine. And: select([docs.c.DocID], bind=db).execute() Gives: TypeError: __init__() got an unexpected keyword argument 'bind' 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Choosing a few columns out a query object
I see the difference between getting an object (with all the columns)
and doing an SQL statement.
As fas as I can see, yes it is bounded.
The code is:
from sqlalchemy import *
metadata = MetaData()
docs = Table('docs', metadata)
docs.append_column(Column('DocID', Integer, primary_key=True))
docs.append_column(Column('Path', String(120)))
docs.append_column(Column('Complete', Boolean))
class Doc(object):
def __init__(self, id, path, state):
self.DocID = id
self.Path = path
self.Complete = state
def __str__(self):
return '(%s) %s %s' %(self.DocID, self.Path, self.Complete)
if __name__ == __main__:
mapper(Doc, docs)
db = create_engine( 'sqlite:///mydb' )
db.echo = False
s = create_session(bind_to = db)
q = s.query(Doc)
On Jul 25, 2:16 pm, svilen [EMAIL PROTECTED] wrote:
On Wednesday 25 July 2007 15:01:59 alex.schenkman wrote: Hello:
How do I get only a few columns from a query object?
q = session.query(Document).select_by(Complete=False)
would give me a list of rows (all columns) where Complete == False.
this would give u a list of objects, not rows. Eventualy u can disable
all references not to get loaded. query.select() takes a premade sql
statement but it should have enough columns to construct the object.
I have seen the select([doc.c.name]) notation but it doesn't work
for me.
these are plain sql constructs (non-ORM), a somewhat different beast.
select([docs.c.DocID]).execute()
Gives me:
sqlalchemy.exceptions.InvalidRequestError: This Compiled object is
not bound to any engine.
is your table's metadata bound to an engine?
--~--~-~--~~~---~--~~
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: Choosing a few columns out a query object
from sqlalchemy import *
metadata = MetaData()
docs = Table('docs', metadata)
docs.append_column(Column('DocID', Integer, primary_key=True))
docs.append_column(Column('Path', String(120)))
docs.append_column(Column('Complete', Boolean))
class Doc(object):
def __init__(self, id, path, state):
self.DocID = id
self.Path = path
self.Complete = state
def __str__(self):
return '(%s) %s %s' %(self.DocID, self.Path, self.Complete)
if __name__ == __main__:
mapper(Doc, docs)
db = create_engine( 'sqlite:///mydb' )
db.echo = False
s = create_session(bind_to = db)
q = s.query(Doc)
i'm no expert but i dont see where u bind the metadata to the db.
u are binding the session - which isn't needed usualy.
--~--~-~--~~~---~--~~
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: autoload'ing metadata
another version, separated autoload from code-generation, which is now the __main__ test. http://dbcook.svn.sourceforge.net/viewvc/*checkout*/dbcook/trunk/autoload.py now it is possible to do something like: $ python autoload.py postgres://[EMAIL PROTECTED]/db1 | python - sqlite:///db2 copying the structure of input db1 database into the output db2. ciao svilen this is along the recent threads about metadata consistency between code and DB, and the DB-migration. Both these require a full metadata reflection from database. Here a version of autocode.py, hacked for couple of hours. It has more systematic approach, replaces back column types with SA ones, has sqlite and postgress, and is somewhat simpler but more dense. Output also looks nicer (nested identation). Not tested for mssql. my idea is to use this metadata-reflection as starting point towards model-migration technology or framework or whatever. one way is to put all metadata-reflection in the dialects themselves. Maybe there should be reflect_metadata() method, which will extract all tables/names, indexes, etc. This is what i like, although it means hacking 10 files instead of one. But it would be more easier/consistent on the long run. Another way is to pull all reflection stuff out of dialects, or at least separate it somehow. anyway. http://www.sqlalchemy.org/trac/wiki/UsageRecipes/AutoCode#autoload2 codeorAutoCode3 using some metadata howto from: http://sqlzoo.cn/howto/source/z.dir/tip137084/i12meta.xml --~--~-~--~~~---~--~~ 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: Consistency with DB while modifying metadata
On Jul 25, 2007, at 4:57 AM, Anton V. Belyaev wrote: I believe this should be done somehow automatically. Because everyone needs this. There should be two separate disjoint options: 1) Autoload, when working with previously created database for rapid start. Columns arent specified at all in Python code (SQLAlchemy). we do it 2) Tables are specified in the code. Database tables might already exist and might not. And when issuing create_all(), all the situations should be handled correctly: 2a) If tables exist in DB and match Python-defined, ok. we do it (minus the matching part) 2b) If tables do not exist in DB they are created, ok. we do it 2c) If tables exist in DB and there is mismatch with Python-defined, an exception is raised. new feature. however, a lot of people wouldnt use this feature. For one, its not a requirement that a Table object match whats in the database. its often the case that the Table does not define every column in the DB, or has different types, or is representing a view, etc. Secondly, reflection of a table is a big performance hit and not everyone wants that hit at the start of their appication or at the start of each child process. Thirdly, people also may be serializing their Table constructs in pickled files or similar so that the reflection step can be bypassed, thus increasing performance. To me its a nice to have but in practice it would probably get in the way more often than not if it was always on. but why not just use autoload=True across the board in the first place and eliminate the chance of any errors ? 1) I dont know if tables exist. I might need to create them. that implies youve already defined explcit Colums in your Tables; reflection is not needed in this case (except for this verify the table feature). 2) When they exist, autoloading them might cause inconsistency with SQLAlchemy-defined tables in sources. This is exactly what I am trying to avoid. again, im not opposed to this feature and ill patch in an adequate (and fully unit-tested) implementation. but have you actually ever *had* this problem? or is it just hypothetical ? --~--~-~--~~~---~--~~ 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: Choosing a few columns out a query object
On Jul 25, 2007, at 8:51 AM, alex.schenkman wrote:
I see the difference between getting an object (with all the columns)
and doing an SQL statement.
As fas as I can see, yes it is bounded.
The code is:
from sqlalchemy import *
metadata = MetaData()
docs = Table('docs', metadata)
docs.append_column(Column('DocID', Integer, primary_key=True))
docs.append_column(Column('Path', String(120)))
docs.append_column(Column('Complete', Boolean))
class Doc(object):
def __init__(self, id, path, state):
self.DocID = id
self.Path = path
self.Complete = state
def __str__(self):
return '(%s) %s %s' %(self.DocID, self.Path, self.Complete)
if __name__ == __main__:
mapper(Doc, docs)
db = create_engine( 'sqlite:///mydb' )
db.echo = False
s = create_session(bind_to = db)
q = s.query(Doc)
alex -
first of all upgrade to 0.3.10 so the newer syntax here works.
then either:
metadata.bind = your engine
or
table.select(bind=your engine).execute()
or
engine.execute(table.select())
etc.
--~--~-~--~~~---~--~~
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: UnicodeDecodeError: 'utf8' codec can't decode bytes in position 94-96: invalid data
seems like convert_unicode=True (or Unicode type) is already happening there. its not going to play well with MySQL client encoding if you have use_unicode=1 turned on in my.cnf or on MySQLDB. On Jul 25, 2007, at 9:12 AM, Arun Kumar PG wrote: the stack trace is as follows: File /aab/sqlalchemy/orm/query.py, line 331, in instances File /aab/sqlalchemy/orm/mapper.py, line 1201, in _instance File /aab/sqlalchemy/orm/mapper.py, line 1236, in populate_instance File /aab/sqlalchemy/orm/interfaces.py, line 77, in execute File /aab/sqlalchemy/orm/strategies.py, line 39, in process_row File /aab/sqlalchemy/engine/base.py, line 725, in __getitem__ File /aab/sqlalchemy/engine/base.py, line 632, in _get_col File /aab/sqlalchemy/types.py, line 178, in convert_result_value File /usr/lib/python2.4/encodings/utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 94-96: invalid data On 7/25/07, Arun Kumar PG [EMAIL PROTECTED] wrote: Guys, I am getting this error on reading data from a MySQL table. I have specified the charset of the table as utf-8 and collation utf8_general_ci. Do I need to do anything else ? Will convert_unicode=True help? -- Cheers, - A -- Cheers, - A --~--~-~--~~~---~--~~ 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: Consistency with DB while modifying metadata
On Jul 25, 2007, at 12:02 PM, Anton V. Belyaev wrote: again, im not opposed to this feature and ill patch in an adequate (and fully unit-tested) implementation. but have you actually ever *had* this problem? or is it just hypothetical ? For example, a developer modifies the metadata and checks in. Another developer updates and finds strange problems, having the old database. OK, so hypothetical. Im not saying it cant happen, im just saying, its not very *common*, nor is it terribly confusing to resolve if it does happen. --~--~-~--~~~---~--~~ 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: Consistency with DB while modifying metadata
Anton V. Belyaev ha scritto: again, im not opposed to this feature and ill patch in an adequate (and fully unit-tested) implementation. but have you actually ever *had* this problem? or is it just hypothetical ? For example, a developer modifies the metadata and checks in. Another developer updates and finds strange problems, having the old database. Then, a SQL script to migrate the database schema should be provided with the check-in... Please, don't believe SQLAlchemy will help you win the Viet Nam war of computer science (*). It's supposed to help us survive. And it's a lot. I'm happily using autoload since the beginning, I've never used the Table() construct if not to replicate a couple of bugs and submit them. And I think my applications are simpler because of it, not in spite of it :-) http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx http://spyced.blogspot.com/2006/02/why-schema-definition-belongs-in.html (with comments from Mike Bayer, Ian Bicking and others) --~--~-~--~~~---~--~~ 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: Consistency with DB while modifying metadata
On Wednesday 25 July 2007 19:34:50 Marco Mariani wrote: Anton V. Belyaev ha scritto: again, im not opposed to this feature and ill patch in an adequate (and fully unit-tested) implementation. but have you actually ever *had* this problem? or is it just hypothetical ? For example, a developer modifies the metadata and checks in. Another developer updates and finds strange problems, having the old database. Then, a SQL script to migrate the database schema should be provided with the check-in... aha, and someone to write it? i think all this automate whatspossible business is stepping on some toes, and eventualy pulling the carpet under... here's some self-citation: svil wrote: But then - who would want to convert python funcs into sql expressions? The whole sql-book-course-consulting-admin world will collapse... (-:) have fun, and happy trying the autoload.py svil --~--~-~--~~~---~--~~ 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: autoload'ing metadata
here some theory on comparing data trees, in order to produce the changeset edit scripts. http://www.pri.univie.ac.at/Publications/2005/Eder_DAWAK2005_A_Tree_Comparison_Approach_to_Detect.pdf of course full automation is not possible and not needed - but why not do maximum effect/help with minimum resources? --~--~-~--~~~---~--~~ 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: no RowProxy.__getslice__
The trouble is (and, sorry, this is getting beyond SQLAlchemy- specific), that leaves me without any good ideas for how to distinguish sequence types (lists, tuples, and user-defined objects resembling them) from mappings (dicts). i usualy differ between sequences/generators and dicts by if they have or not iteritems() (or similar). The protocols are different enough, u can pick anything, e.g. has_key(). --~--~-~--~~~---~--~~ 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: no RowProxy.__getslice__
Well, the docs you link say slicing should be done via __getitem__ now. Which is also present in dicts of course. Why not approach the problem from the other direction? try: maybedict.keys() except AttributeError: ismapping = True else: ismapping = False ? On 7/25/07, Catherine [EMAIL PROTECTED] wrote: Whoops! Never mind; deprecation is a really good reason. http://docs.python.org/ref/sequence-methods.html __getslice__( self, i, j) Deprecated since release 2.0. The trouble is (and, sorry, this is getting beyond SQLAlchemy- specific), that leaves me without any good ideas for how to distinguish sequence types (lists, tuples, and user-defined objects resembling them) from mappings (dicts). Also, I don't need to at present, but it still leaves it impossible to take a slice from a RowProxy. It seems possibly useful. resultrow[1:2] TypeError: unhashable type So, for the moment, I'm looking into whether I could write a patch for that, then try-and-catch to do my duck typing. If you know a reason RowProxy's -shouldn't- support slicing, say so! - Catherine http://catherinedevlin.blogspot.com --~--~-~--~~~---~--~~ 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: no RowProxy.__getslice__
Yes, that's good! Still, I couldn't help myself and submitted a patch to support slicing: http://www.sqlalchemy.org/trac/ticket/686 It's all of four lines. I love Python. My need is to verify that something *is* a sequence but *is not* a dict, so without the patch, I'd have to check that it doesn't have keys and does have __getitem__... that's, like, maybe two dozen extra characters of clutter! Obviously intolerable. :) On Jul 25, 4:14 pm, Jonathan Ellis [EMAIL PROTECTED] wrote: Well, the docs you link say slicing should be done via __getitem__ now. Which is also present in dicts of course. Why not approach the problem from the other direction? try: maybedict.keys() except AttributeError: ismapping = True else: ismapping = False - Catherine http://catherinedevlin.blogspot.com --~--~-~--~~~---~--~~ 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: no RowProxy.__getslice__
Whoops! Never mind; deprecation is a really good reason. http://docs.python.org/ref/sequence-methods.html __getslice__( self, i, j) Deprecated since release 2.0. The trouble is (and, sorry, this is getting beyond SQLAlchemy- specific), that leaves me without any good ideas for how to distinguish sequence types (lists, tuples, and user-defined objects resembling them) from mappings (dicts). Also, I don't need to at present, but it still leaves it impossible to take a slice from a RowProxy. It seems possibly useful. resultrow[1:2] TypeError: unhashable type So, for the moment, I'm looking into whether I could write a patch for that, then try-and-catch to do my duck typing. If you know a reason RowProxy's -shouldn't- support slicing, say so! - Catherine http://catherinedevlin.blogspot.com --~--~-~--~~~---~--~~ 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] no RowProxy.__getslice__
Hi! Does anyone know if there's a reason sqlalchemy.engine.base.RowProxy doesn't define __getslice__ ? If I resultrow = mytable.select().execute().fetchone() then I can access resultrow[2] or resultrow[4], but not resultrow[2:4]. I ask primarily because checking for __getslice__ is useful for duck typing. Right now, there is no attribute that is present in lists, tuples, and RowProxy's, but absent from dicts... Would a patch defining RowProxy.__getslice__ be welcome or misguided? Thanks! - Catherine Devlin http://catherinedevlin.blogspot.com --~--~-~--~~~---~--~~ 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: Model to Dictionary
why not just pass model_instance.__dict__ ? On 7/23/07, HiTekElvis [EMAIL PROTECTED] wrote: Anybody know a way to change a model into a dictionary? For those to whom it means anything, I'm hoping to pass that dictionary into a formencode.Schema.from_python method. Any ideas? -Josh --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
