[sqlalchemy] Re: a-directional i.e. bi-directional m:m relations
Thanks for the ideas. I thought of all of the above. The one I've been using is the accessor which unions together the necessary things. My question came up when I wondered if there was some even more fundamental way to handle these forwards-backwards cases. I'm glad to know I'm already doing all I can. On Dec 2, 3:32 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 2, 2008, at 5:54 PM, Eric Ongerth wrote: Now when I want to find out whether a Foo has a relation to another Foo, I have to check whether there exists any row in foo_relations that has the given Foo as either as this OR that. Also, what if I need backrefs on the foo_relations mapper? The backref from 'this' and the backref from 'that' would both point to something called a foo, but they would have to be given separate labels in order ot not be conflicting property names -- when really, I would not want to know if a foo was the 'that' or the 'this' of some foo relation. So ideally in a case like this, I could set an option that says the m:m relation is bidirectional, and that the backrefs for both foreign keys in the m:m table should really point to the same place (or at least be unioned together). I have a feeling that would violate some part of the RDBMS standards, and I'm perfectly willing to go without or work around. This is more of a philosophical point for learning's sake -- what do other people do in such cases? you can store two rows in the association table, one for each direction. or provide an accessor which just unions together the forwards and backwards references between Foo objects. or make a readonly relation() that does the appropriate OR logic. I might even try combining both of those techniques somehow. --~--~-~--~~~---~--~~ 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: a-directional i.e. bi-directional m:m relations
there is... u do not want to know if A points B or B points A, u want to know if A and B are related in whatever aspect. That is, A and B are members of some set X denoting that aspect. i.e. moving the belonginess out of A and B alltogether. but this isn't going to make your DB simpler... quite the opposite. On Friday 05 December 2008 10:40:16 Eric Ongerth wrote: Thanks for the ideas. I thought of all of the above. The one I've been using is the accessor which unions together the necessary things. My question came up when I wondered if there was some even more fundamental way to handle these forwards-backwards cases. I'm glad to know I'm already doing all I can. On Dec 2, 3:32 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 2, 2008, at 5:54 PM, Eric Ongerth wrote: Now when I want to find out whether a Foo has a relation to another Foo, I have to check whether there exists any row in foo_relations that has the given Foo as either as this OR that. Also, what if I need backrefs on the foo_relations mapper? The backref from 'this' and the backref from 'that' would both point to something called a foo, but they would have to be given separate labels in order ot not be conflicting property names -- when really, I would not want to know if a foo was the 'that' or the 'this' of some foo relation. So ideally in a case like this, I could set an option that says the m:m relation is bidirectional, and that the backrefs for both foreign keys in the m:m table should really point to the same place (or at least be unioned together). I have a feeling that would violate some part of the RDBMS standards, and I'm perfectly willing to go without or work around. This is more of a philosophical point for learning's sake -- what do other people do in such cases? you can store two rows in the association table, one for each direction. or provide an accessor which just unions together the forwards and backwards references between Foo objects. or make a readonly relation() that does the appropriate OR logic. I might even try combining both of those techniques somehow. --~--~-~--~~~---~--~~ 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: returning primary key of object without know what it is called.
-Original Message- From: sqlalchemy@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Faheem Mitha Sent: 04 December 2008 20:43 To: sqlalchemy@googlegroups.com Subject: [sqlalchemy] returning primary key of object without know what it is called. Hi, I'm trying to figure out how to have an object return its primary key without knowing what it is called. The docs in http://www.sqlalchemy.org/docs/05/sqlalchemy_orm_mapper.html look relevant, for example the function identity_key_from_instance (see entry from docs below), but I'm not clear about usage. The functions on this page look like they are meant to be used as method functions of a mapper object, but how should I construct such a mapper object? In my schema file, I have lines like Mapper(Foo, foo_table) should I be returning an mapper object for use with functions? Ie should I be doing foo_mapper = Mapper(Foo, foo_table) or similar? The section module sqlalchemy.orm.mapper saya This is a semi-private module; the main configurational API of the ORM is available in module sqlalchemy.orm. Does this mean it is not meant to be used in this fashion? Also, I don't understand what is meant by This value is typically also found on the instance state under the attribute name key. in the docs for identity_key_from_instance below. Please CC me on any reply. Thanks and regards, Faheem. You can get the mapper for a given instance using the sqlalchemy.orm.object_mapper function, and that mapper has a 'primary_key_from_instance' method. A generic primary_key function might look like this (untested): import sqlalchemy.orm as orm def get_primary_key(instance): mapper = orm.object_mapper(instance) return mapper.primary_key_from_instance(instance) Hope that helps, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy Sphinx Documentation Preview
Hi, There are some sphinx system messages on: http://www.sqlalchemy.org/docs/sphinxtest/intro.html Reference Documentation¶ * System Message: WARNING/2 (/home/classic/dev/sphinx/doc/build/intro.rst) undefined label: datamapping – if you don't give a link caption the label must precede a section header. - A comprehensive walkthrough of major ORM patterns and techniques. * System Message: WARNING/2 (/home/classic/dev/sphinx/doc/build/intro.rst) undefined label: session – if you don't give a link caption the label must precede a section header. - A detailed description of SQLAlchemy's Session object * System Message: WARNING/2 (/home/classic/dev/sphinx/doc/build/intro.rst) undefined label: engines – if you don't give a link caption the label must precede a section header. - Describes SQLAlchemy's database-connection facilities, including connection documentation and working with connections and transactions. * System Message: WARNING/2 (/home/classic/dev/sphinx/doc/build/intro.rst) undefined label: pooling – if you don't give a link caption the label must precede a section header. - Further detail about SQLAlchemy's connection pool library. On Wed, Dec 3, 2008 at 11:36 PM, Michael Bayer [EMAIL PROTECTED] wrote: We've created a new branch and are in the process of migrating all of our documentation over to Sphinx. The process has gone well and we have a working demo of the full system online. By converting to Sphinx, we get the huge advantage of being on a standardized platform that everyone can understand and contribute towards. All kinds of wacky old code, some of it four or more years old, has been removed (and we thank it for its service). The docs are now split into Main Documentation and API Reference. Because Sphinx allows very flexible layout of docstring-generated documentation, Main Documentation is shrinking and the docstrings used by API Reference, which is an all new section that replaces the old straight down modules display, are growing dramatically, which means more documentation is centralized across the site/pydocs and there's less redundancy. What we are now looking for with regards to the demo is: - comments/suggestions regarding layout, styling. Some layout changes were forced by Sphinx, and others (most) are improvements that Sphinx allowed us to achieve. I'm not a CSS guru or a designer so suggested patches to the CSS and templates would be welcome. If Todd Grimason is out there, feel free to chime in :) . - proofreaders. The content on the demo is maybe 60% of the way there and we're combing through finding issues related to the Sphinx conversion, as well as things that have just been wrong all along. We would love to get patches against the doc build correcting as many issues as possible. - authors. No excuses now , we're on the most standard platform there is for docs. If you have better verbiage for sections or docstrings which aren't clear, are nonexistent (like many of the dialects) or are out of date (theres lots), we want to see suggestions. More elaborate suggestions regarding new sections and organization are welcome too as the structure is completely open ended. - people who understand LaTex to work on the PDF side of things. This one's totally over my head as far as how to get a pdf file out of this thing (pdflatex is fairly inscrutable on a mac). Sphinx 0.6 is required, which at the time of this writing is not yet released so you'll have to check out Sphinx from its mercurial repository if you want to do builds. View the content online at: http://www.sqlalchemy.org/docs/sphinxtest/ Checkout the SVN branch and do a build: http://svn.sqlalchemy.org/sqlalchemy/branches/sphinx --~--~-~--~~~---~--~~ 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] any easy way to make a just-out-of-db object readonly?
i'm asking about SA-related stuff, i know how to handle the python side. how to lock relations, collections etc - how to make an instance readonly? and eventualy if it is poosible after that to unlock that instance at some point - so lock all the user-visible stuff but leave some flag _locked writable. ciao svilen --~--~-~--~~~---~--~~ 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: returning primary key of object without know what it is called.
On Fri, 5 Dec 2008, King Simon-NFHD78 wrote: You can get the mapper for a given instance using the sqlalchemy.orm.object_mapper function, and that mapper has a 'primary_key_from_instance' method. A generic primary_key function might look like this (untested): import sqlalchemy.orm as orm def get_primary_key(instance): mapper = orm.object_mapper(instance) return mapper.primary_key_from_instance(instance) Hope that helps, Hi Simon, Thanks, that is very helpful. That's exactly what I need. Regards, Faheem. --~--~-~--~~~---~--~~ 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] Cascading deletes to children
Hi all,I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work! I'm
using MySQL with the InnoDB engine, and have played with all the variation
of the onupdate, ondelete and cascade arguments I can think of.
The problem is that immediately before the DELETE command is sent to MySQL,
there are UPDATE commands nulling out the foreign key references of the
child objects, so MySQL doesn't trigger it's ON DELETE CASCADE action, and
for some reason cascade=all, delete-orphan doesn't clean up the children
with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all, delete,
delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much appreciated!
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: SQLAlchemy Sphinx Documentation Preview
The searching is a bit weird. If I search for Adjacency I get no results. If I search for adjacency (all lower case) I get results, the first of which has an upper-cased Adjacency. Otherwise they look nice and I'm sure will look nicer-yet as time goes on! -- Jon --~--~-~--~~~---~--~~ 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: any easy way to make a just-out-of-db object readonly?
On Dec 5, 2008, at 11:10 AM, [EMAIL PROTECTED] wrote: i'm asking about SA-related stuff, i know how to handle the python side. how to lock relations, collections etc - how to make an instance readonly? and eventualy if it is poosible after that to unlock that instance at some point - so lock all the user-visible stuff but leave some flag _locked writable. you could perhaps override __setattribute__ --~--~-~--~~~---~--~~ 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: SQLAlchemy Sphinx Documentation Preview
well we have no control over any of thatI don't know that Sphinx search uses case insensitivity for full text searches. On Dec 5, 2008, at 11:53 AM, Jon Nelson wrote: The searching is a bit weird. If I search for Adjacency I get no results. If I search for adjacency (all lower case) I get results, the first of which has an upper-cased Adjacency. Otherwise they look nice and I'm sure will look nicer-yet as time goes on! -- Jon --~--~-~--~~~---~--~~ 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: Cascading deletes to children
use the passive_updates=True, passive_deletes='all' flags. These
are described at
http://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqlalchemy.orm_modfunc_relation
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work!
I'm using MySQL with the InnoDB engine, and have played with all the
variation of the onupdate, ondelete and cascade arguments I can
think of.
The problem is that immediately before the DELETE command is sent to
MySQL, there are UPDATE commands nulling out the foreign key
references of the child objects, so MySQL doesn't trigger it's ON
DELETE CASCADE action, and for some reason cascade=all, delete-
orphan doesn't clean up the children with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all, delete,
delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much appreciated!
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascading deletes to children
actually, use passive_deletes=True, not 'all'. It will issue DELETEs
only for collections that are already loaded, this doesn't break
anything and prevents unnecessary SELECTs of unloaded collections.
The True setting is needed so that the session can update the state of
those collections during the flush process.
On Dec 5, 2008, at 12:29 PM, Michael Bayer wrote:
use the passive_updates=True, passive_deletes='all' flags. These
are described at
http://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqlalchemy.orm_modfunc_relation
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work!
I'm using MySQL with the InnoDB engine, and have played with all
the variation of the onupdate, ondelete and cascade arguments I can
think of.
The problem is that immediately before the DELETE command is sent
to MySQL, there are UPDATE commands nulling out the foreign key
references of the child objects, so MySQL doesn't trigger it's ON
DELETE CASCADE action, and for some reason cascade=all, delete-
orphan doesn't clean up the children with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all,
delete, delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much appreciated!
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: any easy way to make a just-out-of-db object readonly?
On 05.12.2008 17:10 Uhr, [EMAIL PROTECTED] wrote: i'm asking about SA-related stuff, i know how to handle the python side. how to lock relations, collections etc - how to make an instance readonly? and eventualy if it is poosible after that to unlock that instance at some point - so lock all the user-visible stuff but leave some flag _locked writable. You might register a MapperExtension with your mapper. Inside the before_*() methods you could perform some checks in order to avoid any kind of write operations or modifications. -aj --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:[EMAIL PROTECTED] title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard
[sqlalchemy] Re: any easy way to make a just-out-of-db object readonly?
On Friday 05 December 2008 19:22, Michael Bayer wrote: On Dec 5, 2008, at 11:10 AM, [EMAIL PROTECTED] wrote: i'm asking about SA-related stuff, i know how to handle the python side. how to lock relations, collections etc - how to make an instance readonly? and eventualy if it is poosible after that to unlock that instance at some point - so lock all the user-visible stuff but leave some flag _locked writable. you could perhaps override __setattribute__ yeah but what to do with collections... or should i override collectionclass... hmm. --~--~-~--~~~---~--~~ 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: any easy way to make a just-out-of-db object readonly?
ah yes, i forgot that already have that in dbcook! but i dont think it will avoid adding things to collections. okay thanks i'll dig further. On Friday 05 December 2008 19:39, Andreas Jung wrote: On 05.12.2008 17:10 Uhr, [EMAIL PROTECTED] wrote: i'm asking about SA-related stuff, i know how to handle the python side. how to lock relations, collections etc - how to make an instance readonly? and eventualy if it is poosible after that to unlock that instance at some point - so lock all the user-visible stuff but leave some flag _locked writable. You might register a MapperExtension with your mapper. Inside the before_*() methods you could perform some checks in order to avoid any kind of write operations or modifications. -aj --~--~-~--~~~---~--~~ 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: Cascading deletes to children
Ah, I should say I'm using SA 0.4.3 - I going to try the same test on
0.5
On Dec 5, 11:36 am, Michael Bayer [EMAIL PROTECTED] wrote:
actually, use passive_deletes=True, not 'all'. It will issue DELETEs
only for collections that are already loaded, this doesn't break
anything and prevents unnecessary SELECTs of unloaded collections.
The True setting is needed so that the session can update the state of
those collections during the flush process.
On Dec 5, 2008, at 12:29 PM, Michael Bayer wrote:
use the passive_updates=True, passive_deletes='all' flags. These
are described
athttp://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqla...
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work!
I'm using MySQL with the InnoDB engine, and have played with all
the variation of the onupdate, ondelete and cascade arguments I can
think of.
The problem is that immediately before the DELETE command is sent
to MySQL, there are UPDATE commands nulling out the foreign key
references of the child objects, so MySQL doesn't trigger it's ON
DELETE CASCADE action, and for some reason cascade=all, delete-
orphan doesn't clean up the children with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all,
delete, delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much appreciated!
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascading deletes to children
Assuming user_id is a surrogate primary key, I dont see any need for
onupdate=CASCADE to be used here. Additionally, ondelete=CASCADE
on your hat.user_id column implies that hat will be deleted when a
user entry is deleted - however your relation has this set up on the
many-to-one side indicating that a user would be deleted when a
hat is deleted.
I think this is the full setup you're looking for:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('user_name', Unicode(16), unique=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id',
ondelete='CASCADE')),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User,
backref=backref(hats, cascade=all, delete, delete-orphan,
passive_deletes=True)
),
}
)
On Dec 5, 2008, at 1:42 PM, James wrote:
Thanks for your quick response! Unfortunately I made the changes you
suggest and I still get the UPDATE commands being sent to the children
before the DELETE on the parent. My model is now:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('user_name', Unicode(16), unique=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id',
onupdate='CASCADE', ondelete='CASCADE')),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all, delete,
delete-orphan, passive_updates=True, passive_deletes=True),
}
)
And I get the same pattern in the log:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
The ondelete and cascade arguments I have should be working in this
situation, right?
Thanks again,
James
On Dec 5, 11:36 am, Michael Bayer [EMAIL PROTECTED] wrote:
actually, use passive_deletes=True, not 'all'. It will issue
DELETEs
only for collections that are already loaded, this doesn't break
anything and prevents unnecessary SELECTs of unloaded collections.
The True setting is needed so that the session can update the state
of
those collections during the flush process.
On Dec 5, 2008, at 12:29 PM, Michael Bayer wrote:
use the passive_updates=True, passive_deletes='all' flags. These
are described
athttp://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqla
...
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work!
I'm using MySQL with the InnoDB engine, and have played with all
the variation of the onupdate, ondelete and cascade arguments I can
think of.
The problem is that immediately before the DELETE command is sent
to MySQL, there are UPDATE commands nulling out the foreign key
references of the child objects, so MySQL doesn't trigger it's ON
DELETE CASCADE action, and for some reason cascade=all, delete-
orphan doesn't clean up the children with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all,
delete, delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much appreciated!
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
[sqlalchemy] Re: Cascading deletes to children
Yep, the same behaviour in 0.5rc4
On Dec 5, 12:44 pm, James [EMAIL PROTECTED] wrote:
Ah, I should say I'm using SA 0.4.3 - I going to try the same test on
0.5
On Dec 5, 11:36 am, Michael Bayer [EMAIL PROTECTED] wrote:
actually, use passive_deletes=True, not 'all'. It will issue DELETEs
only for collections that are already loaded, this doesn't break
anything and prevents unnecessary SELECTs of unloaded collections.
The True setting is needed so that the session can update the state of
those collections during the flush process.
On Dec 5, 2008, at 12:29 PM, Michael Bayer wrote:
use the passive_updates=True, passive_deletes='all' flags. These
are described
athttp://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqla...
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work!
I'm using MySQL with the InnoDB engine, and have played with all
the variation of the onupdate, ondelete and cascade arguments I can
think of.
The problem is that immediately before the DELETE command is sent
to MySQL, there are UPDATE commands nulling out the foreign key
references of the child objects, so MySQL doesn't trigger it's ON
DELETE CASCADE action, and for some reason cascade=all, delete-
orphan doesn't clean up the children with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all,
delete, delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much appreciated!
James
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Cascading deletes to children
Ah! I see - I had the cascade and passive_delete arguments in the
wrong place.
This works as expected in 0.4.3 and 0.5 now.
Thanks for the help
James
On Dec 5, 12:47 pm, Michael Bayer [EMAIL PROTECTED] wrote:
Assuming user_id is a surrogate primary key, I dont see any need for
onupdate=CASCADE to be used here. Additionally, ondelete=CASCADE
on your hat.user_id column implies that hat will be deleted when a
user entry is deleted - however your relation has this set up on the
many-to-one side indicating that a user would be deleted when a
hat is deleted.
I think this is the full setup you're looking for:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('user_name', Unicode(16), unique=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id',
ondelete='CASCADE')),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User,
backref=backref(hats, cascade=all, delete, delete-orphan,
passive_deletes=True)
),
}
)
On Dec 5, 2008, at 1:42 PM, James wrote:
Thanks for your quick response! Unfortunately I made the changes you
suggest and I still get the UPDATE commands being sent to the children
before the DELETE on the parent. My model is now:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('user_name', Unicode(16), unique=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id',
onupdate='CASCADE', ondelete='CASCADE')),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all, delete,
delete-orphan, passive_updates=True, passive_deletes=True),
}
)
And I get the same pattern in the log:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
The ondelete and cascade arguments I have should be working in this
situation, right?
Thanks again,
James
On Dec 5, 11:36 am, Michael Bayer [EMAIL PROTECTED] wrote:
actually, use passive_deletes=True, not 'all'. It will issue
DELETEs
only for collections that are already loaded, this doesn't break
anything and prevents unnecessary SELECTs of unloaded collections.
The True setting is needed so that the session can update the state
of
those collections during the flush process.
On Dec 5, 2008, at 12:29 PM, Michael Bayer wrote:
use the passive_updates=True, passive_deletes='all' flags. These
are described
athttp://www.sqlalchemy.org/docs/05/sqlalchemy_orm.html#docstrings_sqla
...
.
On Dec 5, 2008, at 11:42 AM, James Brady wrote:
Hi all,
I'm trying to get deletes and updates cascaded down from a parent
object to the child objects (connected by ForeignKey).
It all seems pretty simple in the docs, but I can't get it to work!
I'm using MySQL with the InnoDB engine, and have played with all
the variation of the onupdate, ondelete and cascade arguments I can
think of.
The problem is that immediately before the DELETE command is sent
to MySQL, there are UPDATE commands nulling out the foreign key
references of the child objects, so MySQL doesn't trigger it's ON
DELETE CASCADE action, and for some reason cascade=all, delete-
orphan doesn't clean up the children with NULL FKs.
Here's a simplified model:
users_table = Table('tg_user', metadata,
Column('user_id', Integer, primary_key=True),
Column('created', DateTime, default=datetime.now),
mysql_engine='InnoDB',
)
hat_table = Table('hat', metadata,
Column('id', Integer, primary_key=True),
Column('name', Unicode(100)),
Column('user_id', Integer, ForeignKey('tg_user.user_id'),
onupdate='CASCADE', ondelete='CASCADE'),
mysql_engine='InnoDB',
)
class User(object):
pass
class Hat(object):
pass
mapper(User, users_table)
mapper(Hat, hat_table,
properties = {
'user': relation(User, backref=hats, cascade=all,
delete, delete-orphan),
}
)
And the log from SA when I do a User.delete:
BEGIN
UPDATE hat SET user_id=%s WHERE hat.id = %s
[None, 1L]
DELETE FROM tg_user WHERE tg_user.user_id = %s
[1L]
COMMIT
Any help would be much
[sqlalchemy] objects created using sqlalchemy
Hi,
I'm using sqla with the following schema (see below). I'm creating a cell
object implicitly, using the function make_cell and the association proxy
pattern.
def make_cell(patient_obj, snp_obj, snpval):
patient_obj.snps[snp_obj] = snpval
return patient_obj
My question is, is there some way to get my hands on the Cell object that
was just created? If possible, I'd like make_cell to return the cell
object. My immediate reason is that this would make it easy to save the
object using session.save() (there might be some indirect way to do this,
of course), but it would be nice anyway.
Thanks in advance. Please CC me on any reply.
Regards, Faheem.
**
dbschema.py
**
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.associationproxy import association_proxy
from sqlalchemy.orm.collections import attribute_mapped_collection
from datetime import datetime
metadata = MetaData('sqlite:///btsnp.sqlite')
# *patients*
# patient_id (PK)
# (Can use actual patient id as unique/alternate identifier
# Create index).
# sex - list of choices allowed
# age - (0, 140)
# time of death
patient_table = Table(
'patient', metadata,
Column('id', String(20), primary_key=True, index=True),
Column('celfilename', String(30), nullable=False, index=True, unique=True),
Column('sex', String(1)),
)
cell_table = Table(
'cell', metadata,
Column('patient_id', None, ForeignKey('patient.id', onupdate='CASCADE',
ondelete='CASCADE'), index=True, nullable=False, primary_key=True),
Column('snp_id', None, ForeignKey('snp.rsid', onupdate='CASCADE',
ondelete='CASCADE'), index=True, nullable=False, primary_key=True),
Column('snpval_id', None, ForeignKey('snpval.val', onupdate='CASCADE',
ondelete='CASCADE'), index=True, nullable=False)
)
# *snps*
# snp_id (PK)
# name (name of snp)
snp_table = Table(
'snp', metadata,
Column('rsid', String(20), nullable=False, primary_key=True),
Column('chromosome', Integer, nullable=False),
Column('location', Integer, nullable=False),
Column('probe_set_id', String(20), nullable=False, unique=True),
Column('allele', String(3), nullable=False),
)
# *doublets*
# doublet_id (PK)
# seq (two letters AA, AG)
snpval_table = Table(
'snpval', metadata,
Column('val', Integer, primary_key=True),
)
metadata.create_all()
def create_cell(snp, snpval):
return Cell(snp=snp, snpval=snpval)
class Patient(object):
def __init__(self, id, celfilename, sex):
self.id = id
self.celfilename = celfilename
self.sex = sex
def __repr__(self):
return 'Patient %s'%self.id
snps = association_proxy('by_rsid', 'snpval', creator=create_cell)
class Cell(object):
def __init__(self, patient=None, snp=None, snpval=None):
self.patient = patient
self.snp = snp
self.snpval = snpval
def __repr__(self):
return 'Cell %s'%self.snpval
class Snp(object):
def __init__(self, rsid, chromosome, location, probe_set_id, allele):
self.rsid = rsid
self.chromosome = chromosome
self.location = location
self.probe_set_id = probe_set_id
self.allele = allele
def __repr__(self):
return 'SNP %s'%self.rsid
patients = association_proxy('by_patient', 'snpval', creator=create_cell)
class Snpval(object):
def __init__(self, val):
self.val = val
def __repr__(self):
return 'Snpval %s'%self.val
# mapper(Broker, brokers_table, properties={
# 'by_stock': relation(Holding,
# collection_class=attribute_mapped_collection('stock'))
# })
# 'cells' corresponds to a 1 to many relation.
mapper(Patient, patient_table, properties={'cells':relation(Cell,
backref='patient'),
'by_rsid': relation(Cell,
collection_class=attribute_mapped_collection('snp'))}
)
# 'patient_snpval' corresponds to a many to 1 relation.
# 'patient_snpval' corresponds to a 1 to 1 relation.
mapper(Cell, cell_table, properties={'snp':relation(Snp, backref='cells'),
'snpval':cell_table.c.snpval_id,
'snpval_obj':relation(Snpval,
uselist=False, backref='cell')})
mapper(Snp, snp_table, properties={'by_patient': relation(Cell,
collection_class=attribute_mapped_collection('patient'))})
mapper(Snpval, snpval_table)
#print patient_mapper.identity_key_from_instance()
# 0) Create doublet (2 letters).
# 1) Enter row names (cols) and patient names( snp ids).
# 2) Look at text files and update linker tables.
**
[sqlalchemy] Re: objects created using sqlalchemy
On Dec 5, 2008, at 3:01 PM, Faheem Mitha wrote:
Hi,
I'm using sqla with the following schema (see below). I'm creating a
cell
object implicitly, using the function make_cell and the association
proxy
pattern.
def make_cell(patient_obj, snp_obj, snpval):
patient_obj.snps[snp_obj] = snpval
return patient_obj
My question is, is there some way to get my hands on the Cell object
that
was just created? If possible, I'd like make_cell to return the cell
object. My immediate reason is that this would make it easy to save
the
object using session.save() (there might be some indirect way to do
this,
of course), but it would be nice anyway.
there's no need to session.save() any objects created within
associationproxy - when the parent object is saved, or if the parent
is already saved, any attachments are also saved using the on-by-
default save-update cascade.
Thanks in advance. Please CC me on any reply.
Regards,
Faheem.
**
dbschema.py
**
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.associationproxy import association_proxy
from sqlalchemy.orm.collections import attribute_mapped_collection
from datetime import datetime
metadata = MetaData('sqlite:///btsnp.sqlite')
# *patients*
# patient_id (PK)
# (Can use actual patient id as unique/alternate identifier
# Create index).
# sex - list of choices allowed
# age - (0, 140)
# time of death
patient_table = Table(
'patient', metadata,
Column('id', String(20), primary_key=True, index=True),
Column('celfilename', String(30), nullable=False, index=True,
unique=True),
Column('sex', String(1)),
)
cell_table = Table(
'cell', metadata,
Column('patient_id', None, ForeignKey('patient.id',
onupdate='CASCADE', ondelete='CASCADE'), index=True, nullable=False,
primary_key=True),
Column('snp_id', None, ForeignKey('snp.rsid',
onupdate='CASCADE', ondelete='CASCADE'), index=True,
nullable=False, primary_key=True),
Column('snpval_id', None, ForeignKey('snpval.val',
onupdate='CASCADE', ondelete='CASCADE'), index=True, nullable=False)
)
# *snps*
# snp_id (PK)
# name (name of snp)
snp_table = Table(
'snp', metadata,
Column('rsid', String(20), nullable=False, primary_key=True),
Column('chromosome', Integer, nullable=False),
Column('location', Integer, nullable=False),
Column('probe_set_id', String(20), nullable=False, unique=True),
Column('allele', String(3), nullable=False),
)
# *doublets*
# doublet_id (PK)
# seq (two letters AA, AG)
snpval_table = Table(
'snpval', metadata,
Column('val', Integer, primary_key=True),
)
metadata.create_all()
def create_cell(snp, snpval):
return Cell(snp=snp, snpval=snpval)
class Patient(object):
def __init__(self, id, celfilename, sex):
self.id = id
self.celfilename = celfilename
self.sex = sex
def __repr__(self):
return 'Patient %s'%self.id
snps = association_proxy('by_rsid', 'snpval', creator=create_cell)
class Cell(object):
def __init__(self, patient=None, snp=None, snpval=None):
self.patient = patient
self.snp = snp
self.snpval = snpval
def __repr__(self):
return 'Cell %s'%self.snpval
class Snp(object):
def __init__(self, rsid, chromosome, location, probe_set_id,
allele):
self.rsid = rsid
self.chromosome = chromosome
self.location = location
self.probe_set_id = probe_set_id
self.allele = allele
def __repr__(self):
return 'SNP %s'%self.rsid
patients = association_proxy('by_patient', 'snpval',
creator=create_cell)
class Snpval(object):
def __init__(self, val):
self.val = val
def __repr__(self):
return 'Snpval %s'%self.val
# mapper(Broker, brokers_table, properties={
# 'by_stock': relation(Holding,
# collection_class=attribute_mapped_collection('stock'))
# })
# 'cells' corresponds to a 1 to many relation.
mapper(Patient, patient_table, properties={'cells':relation(Cell,
backref='patient'),
'by_rsid': relation(Cell,
collection_class=attribute_mapped_collection('snp'))}
)
# 'patient_snpval' corresponds to a many to 1 relation.
# 'patient_snpval' corresponds to a 1 to 1 relation.
mapper(Cell, cell_table, properties={'snp':relation(Snp,
backref='cells'),
'snpval':cell_table.c.snpval_id,
'snpval_obj':relation(Snpval,
uselist=False, backref='cell')})
mapper(Snp, snp_table, properties={'by_patient': relation(Cell,
[sqlalchemy] MySQL, unions and ordering
Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ 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: MySQL, unions and ordering
try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ 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: MySQL, unions and ordering
Thanks for the quick response! The following does *not* work. Am I making the call incorrectly? sel = union_all(*[q.self_group() for q in querylist]) On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED] wrote: try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ 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: MySQL, unions and ordering
that's correct. what does it render ? On Dec 5, 2008, at 4:17 PM, Bo Shi wrote: Thanks for the quick response! The following does *not* work. Am I making the call incorrectly? sel = union_all(*[q.self_group() for q in querylist]) On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED] wrote: try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ 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] utf hex instead of utf-8 return
greetings,
SA (0.5.0rc1) keeps returning utf hex in stead of utf-8 and in the
process driving me batty. all the mysql setup is fine, the chars look
good and are umlauting to goethe's delight. moreover, insert and
select are working perfectly with the MySQLdb api on three different
*nix systems, two servers, ... it works.
where things fall apart is on the retrieval side of SA; inserts are
fine (using the config_args = {'charset':'utf8'} dict in the
create_engine call).
for example, ë, the latin small letter e with diaeresis, is stored in
mysql hex as C3 AB; using the MySQldb client, this is exactly what i
get back: '\xc3\xab' (in the # -*- coding: UTF-8 -*- environment) no
further codecs work required. SA, on the other hand, hands me back the
utf-hex representation, '\xeb'.
there must be some setting that i'm missing that'll give the
appropriate utf-8 representation at the SA (api) level. any ideas,
suggestions?
thx
yes, i could do '\xeb'.encode('utf8) but it's not an option. we got
too much data to deal with and MySQLdb is working perfectly well
without the extra step. thx.
--~--~-~--~~~---~--~~
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: MySQL, unions and ordering
from sqlalchemy import * s = select([x, y]).select_from(table) print union_all(s.self_group(), s.self_group()).order_by(foo) (SELECT x, y FROM table) UNION ALL (SELECT x, y FROM table) ORDER BY foo On Dec 5, 2008, at 4:17 PM, Bo Shi wrote: Thanks for the quick response! The following does *not* work. Am I making the call incorrectly? sel = union_all(*[q.self_group() for q in querylist]) On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED] wrote: try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ 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: utf hex instead of utf-8 return
I'm not sure of the mechanics of what you're experiencing, but make
sure you use charset=utf8use_unicode=0 with MySQL.
On Dec 5, 2008, at 4:17 PM, n00b wrote:
greetings,
SA (0.5.0rc1) keeps returning utf hex in stead of utf-8 and in the
process driving me batty. all the mysql setup is fine, the chars look
good and are umlauting to goethe's delight. moreover, insert and
select are working perfectly with the MySQLdb api on three different
*nix systems, two servers, ... it works.
where things fall apart is on the retrieval side of SA; inserts are
fine (using the config_args = {'charset':'utf8'} dict in the
create_engine call).
for example, ë, the latin small letter e with diaeresis, is stored in
mysql hex as C3 AB; using the MySQldb client, this is exactly what i
get back: '\xc3\xab' (in the # -*- coding: UTF-8 -*- environment) no
further codecs work required. SA, on the other hand, hands me back the
utf-hex representation, '\xeb'.
there must be some setting that i'm missing that'll give the
appropriate utf-8 representation at the SA (api) level. any ideas,
suggestions?
thx
yes, i could do '\xeb'.encode('utf8) but it's not an option. we got
too much data to deal with and MySQLdb is working perfectly well
without the extra step. thx.
--~--~-~--~~~---~--~~
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: MySQL, unions and ordering
I had to upgrade to 0.4.7 from 0.4.2, but your sample query works, however, my application of it does not. Sorry I'm being so light on details, I'll try to reproduce with a complete sample versus using snippets of production code. Each select statement is generated like so: sel = select(pre_select + selectlist, from_obj=join_datatables(tables)) I apply self_group() using a list comprehension and if I print each select statement in the list individually, the parentheses show up. If I then union_all(*querylist) and print that, the parentheses disappear. Weird. I should note that the individual selects have filters, an order by clause and a limit, but the following works fine so I would not expect that to be a problem. from sqlalchemy import * s = select([x, y]).select_from(table) print s.self_group() (SELECT x, y FROM table) print union_all(s.self_group(), s.self_group()).order_by(foo) (SELECT x, y FROM table) UNION ALL (SELECT x, y FROM table) ORDER BY foo print union_all(s.limit(10).self_group(), s.limit(10).self_group()).order_by(foo).limit(10) (SELECT x, y FROM table LIMIT 10) UNION ALL (SELECT x, y FROM table LIMIT 10) ORDER BY foo LIMIT 10 import sqlalchemy as sa sa.__version__ '0.4.7' On Fri, Dec 5, 2008 at 4:23 PM, Michael Bayer [EMAIL PROTECTED] wrote: from sqlalchemy import * s = select([x, y]).select_from(table) print union_all(s.self_group(), s.self_group()).order_by(foo) (SELECT x, y FROM table) UNION ALL (SELECT x, y FROM table) ORDER BY foo On Dec 5, 2008, at 4:17 PM, Bo Shi wrote: Thanks for the quick response! The following does *not* work. Am I making the call incorrectly? sel = union_all(*[q.self_group() for q in querylist]) On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED] wrote: try calling self_group() on each select object. On Dec 5, 2008, at 3:55 PM, Bo Shi wrote: Hi all, There appear to be some nuances to using order by statements with set operations like unions in MySQL but the following is allowed*: (SELECT a,b from DBA.tbl ORDER BY b LIMIT 5) UNION ALL (SELECT a,b from DBB.tbl ORDER BY b LIMIT 5) ORDER BY b When I attempt to generate such a statement with: union_all(*list_of_select_objs), The SQL generated lacks parentheses around the SELECT statements (in addition to dropping the order by clauses, but that appears to be expected behavior). Is there a way to put the parentheses in? *just an example, the query i've written is meaningless/useless :-) -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 -- Bo Shi 207-469-8264 --~--~-~--~~~---~--~~ 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: MySQL, unions and ordering
there's logic which is removing the order_by's from the selects, and
in that case this is what's blowing away the parenthesis as well.
Some databases don't even allow ORDER BY inside of the queries used in
a UNION since in the absense of LIMIT/OFFSET, which also is not
standard SQL, they have no effect.
However I dont think its good form for SQLA to be whacking the ORDER
BY from the unions if that is in fact what was requested.So this
behavior is changed in the 0.5 series in r5425. As far as the 0.4
series, we're only supporting critical bugfixes there and I'd like to
avoid any behavioral changes (0.4 is also on a more conservative
release schedule). If you're truly stuck with 0.4, you can use
select.order_by(...).alias().select() to get an equivalent query which
is insulated from changes (and is probably more compatible across
databases), or to get exactly the same SQL here's a safe monkeypatch
approach:
from sqlalchemy import *
s = select([x, y]).select_from(table)
def frozen_order_by(s):
s = s.self_group()
s.order_by = lambda *args: s
return s
qlist = [s.limit(10).order_by('x'), s.limit(10).order_by('x')]
print union_all(*[frozen_order_by(q) for q in
qlist]).order_by(foo).limit(10)
frozen_order_by() calls self_group() thereby generating a new select()
so that the original is unchanged.
On Dec 5, 2008, at 5:08 PM, Bo Shi wrote:
Oh, check this out:
(SA 0.4.7)
from sqlalchemy import *
s = select([x, y]).select_from(table)
qlist = [s.limit(10).order_by('x').self_group(),
s.limit(10).order_by('x').self_group()]
print union_all(*qlist).order_by(foo).limit(10)
SELECT x, y
FROM table
LIMIT 10 UNION ALL SELECT x, y
FROM table
LIMIT 10 ORDER BY foo
LIMIT 10
for q in qlist:
... print q
...
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
On Fri, Dec 5, 2008 at 4:55 PM, Bo Shi [EMAIL PROTECTED] wrote:
I had to upgrade to 0.4.7 from 0.4.2, but your sample query works,
however, my application of it does not.
Sorry I'm being so light on details, I'll try to reproduce with a
complete sample versus using snippets of production code.
Each select statement is generated like so:
sel = select(pre_select + selectlist,
from_obj=join_datatables(tables))
I apply self_group() using a list comprehension and if I print each
select statement in the list individually, the parentheses show up.
If I then union_all(*querylist) and print that, the parentheses
disappear.
Weird.
I should note that the individual selects have filters, an order by
clause and a limit, but the following works fine so I would not
expect
that to be a problem.
from sqlalchemy import *
s = select([x, y]).select_from(table)
print s.self_group()
(SELECT x, y
FROM table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
print union_all(s.limit(10).self_group(),
s.limit(10).self_group()).order_by(foo).limit(10)
(SELECT x, y
FROM table
LIMIT 10) UNION ALL (SELECT x, y
FROM table
LIMIT 10) ORDER BY foo
LIMIT 10
import sqlalchemy as sa
sa.__version__
'0.4.7'
On Fri, Dec 5, 2008 at 4:23 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
from sqlalchemy import *
s = select([x, y]).select_from(table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
On Dec 5, 2008, at 4:17 PM, Bo Shi wrote:
Thanks for the quick response!
The following does *not* work. Am I making the call incorrectly?
sel = union_all(*[q.self_group() for q in querylist])
On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
try calling self_group() on each select object.
On Dec 5, 2008, at 3:55 PM, Bo Shi wrote:
Hi all,
There appear to be some nuances to using order by statements with
set
operations like unions in MySQL but the following is allowed*:
(SELECT a,b from DBA.tbl ORDER BY b LIMIT 5)
UNION ALL
(SELECT a,b from DBB.tbl ORDER BY b LIMIT 5)
ORDER BY b
When I attempt to generate such a statement with:
union_all(*list_of_select_objs),
The SQL generated lacks parentheses around the SELECT
statements (in
addition to dropping the order by clauses, but that appears to be
expected behavior). Is there a way to put the parentheses in?
*just an example, the query i've written is meaningless/
useless :-)
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--~--~-~--~~~---~--~~
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
[sqlalchemy] Re: a-directional i.e. bi-directional m:m relations
Oh, right. I don't know what type of brain fog obscured that basic relational fact, except that I may have been burning my synapses a bit too hot lately resulting in a deplorable deficit of neurotransmitters. Thank you for helping me regain the sight of the obvious. On Dec 5, 1:16 am, [EMAIL PROTECTED] wrote: there is... u do not want to know if A points B or B points A, u want to know if A and B are related in whatever aspect. That is, A and B are members of some set X denoting that aspect. i.e. moving the belonginess out of A and B alltogether. but this isn't going to make your DB simpler... quite the opposite. On Friday 05 December 2008 10:40:16 Eric Ongerth wrote: Thanks for the ideas. I thought of all of the above. The one I've been using is the accessor which unions together the necessary things. My question came up when I wondered if there was some even more fundamental way to handle these forwards-backwards cases. I'm glad to know I'm already doing all I can. On Dec 2, 3:32 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 2, 2008, at 5:54 PM, Eric Ongerth wrote: Now when I want to find out whether a Foo has a relation to another Foo, I have to check whether there exists any row in foo_relations that has the given Foo as either as this OR that. Also, what if I need backrefs on the foo_relations mapper? The backref from 'this' and the backref from 'that' would both point to something called a foo, but they would have to be given separate labels in order ot not be conflicting property names -- when really, I would not want to know if a foo was the 'that' or the 'this' of some foo relation. So ideally in a case like this, I could set an option that says the m:m relation is bidirectional, and that the backrefs for both foreign keys in the m:m table should really point to the same place (or at least be unioned together). I have a feeling that would violate some part of the RDBMS standards, and I'm perfectly willing to go without or work around. This is more of a philosophical point for learning's sake -- what do other people do in such cases? you can store two rows in the association table, one for each direction. or provide an accessor which just unions together the forwards and backwards references between Foo objects. or make a readonly relation() that does the appropriate OR logic. I might even try combining both of those techniques somehow. --~--~-~--~~~---~--~~ 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: MySQL, unions and ordering
Thanks; the monkeypatch approach works nicely. Using the alias()
method will raise
AttributeError: 'Alias' object has no attribute '_order_by_clause'
On Fri, Dec 5, 2008 at 7:25 PM, Michael Bayer [EMAIL PROTECTED] wrote:
there's logic which is removing the order_by's from the selects, and
in that case this is what's blowing away the parenthesis as well.
Some databases don't even allow ORDER BY inside of the queries used in
a UNION since in the absense of LIMIT/OFFSET, which also is not
standard SQL, they have no effect.
However I dont think its good form for SQLA to be whacking the ORDER
BY from the unions if that is in fact what was requested.So this
behavior is changed in the 0.5 series in r5425. As far as the 0.4
series, we're only supporting critical bugfixes there and I'd like to
avoid any behavioral changes (0.4 is also on a more conservative
release schedule). If you're truly stuck with 0.4, you can use
select.order_by(...).alias().select() to get an equivalent query which
is insulated from changes (and is probably more compatible across
databases), or to get exactly the same SQL here's a safe monkeypatch
approach:
from sqlalchemy import *
s = select([x, y]).select_from(table)
def frozen_order_by(s):
s = s.self_group()
s.order_by = lambda *args: s
return s
qlist = [s.limit(10).order_by('x'), s.limit(10).order_by('x')]
print union_all(*[frozen_order_by(q) for q in
qlist]).order_by(foo).limit(10)
frozen_order_by() calls self_group() thereby generating a new select()
so that the original is unchanged.
On Dec 5, 2008, at 5:08 PM, Bo Shi wrote:
Oh, check this out:
(SA 0.4.7)
from sqlalchemy import *
s = select([x, y]).select_from(table)
qlist = [s.limit(10).order_by('x').self_group(),
s.limit(10).order_by('x').self_group()]
print union_all(*qlist).order_by(foo).limit(10)
SELECT x, y
FROM table
LIMIT 10 UNION ALL SELECT x, y
FROM table
LIMIT 10 ORDER BY foo
LIMIT 10
for q in qlist:
... print q
...
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
(SELECT x, y
FROM table ORDER BY x
LIMIT 10)
On Fri, Dec 5, 2008 at 4:55 PM, Bo Shi [EMAIL PROTECTED] wrote:
I had to upgrade to 0.4.7 from 0.4.2, but your sample query works,
however, my application of it does not.
Sorry I'm being so light on details, I'll try to reproduce with a
complete sample versus using snippets of production code.
Each select statement is generated like so:
sel = select(pre_select + selectlist,
from_obj=join_datatables(tables))
I apply self_group() using a list comprehension and if I print each
select statement in the list individually, the parentheses show up.
If I then union_all(*querylist) and print that, the parentheses
disappear.
Weird.
I should note that the individual selects have filters, an order by
clause and a limit, but the following works fine so I would not
expect
that to be a problem.
from sqlalchemy import *
s = select([x, y]).select_from(table)
print s.self_group()
(SELECT x, y
FROM table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
print union_all(s.limit(10).self_group(),
s.limit(10).self_group()).order_by(foo).limit(10)
(SELECT x, y
FROM table
LIMIT 10) UNION ALL (SELECT x, y
FROM table
LIMIT 10) ORDER BY foo
LIMIT 10
import sqlalchemy as sa
sa.__version__
'0.4.7'
On Fri, Dec 5, 2008 at 4:23 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
from sqlalchemy import *
s = select([x, y]).select_from(table)
print union_all(s.self_group(), s.self_group()).order_by(foo)
(SELECT x, y
FROM table) UNION ALL (SELECT x, y
FROM table) ORDER BY foo
On Dec 5, 2008, at 4:17 PM, Bo Shi wrote:
Thanks for the quick response!
The following does *not* work. Am I making the call incorrectly?
sel = union_all(*[q.self_group() for q in querylist])
On Fri, Dec 5, 2008 at 4:08 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
try calling self_group() on each select object.
On Dec 5, 2008, at 3:55 PM, Bo Shi wrote:
Hi all,
There appear to be some nuances to using order by statements with
set
operations like unions in MySQL but the following is allowed*:
(SELECT a,b from DBA.tbl ORDER BY b LIMIT 5)
UNION ALL
(SELECT a,b from DBB.tbl ORDER BY b LIMIT 5)
ORDER BY b
When I attempt to generate such a statement with:
union_all(*list_of_select_objs),
The SQL generated lacks parentheses around the SELECT
statements (in
addition to dropping the order by clauses, but that appears to be
expected behavior). Is there a way to put the parentheses in?
*just an example, the query i've written is meaningless/
useless :-)
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--
Bo Shi
207-469-8264
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
[sqlalchemy] Re: SQLAlchemy Sphinx Documentation Preview
Mike,
Gaetan's right -- I just viewed the site a day after you (Mike) said
that the li issue had been fixed, but they're still too widely
spaced for sure. There are several conflicting (well ok, inheriting/
overriding) settings of line-height across the various css files, and
it does not appear that padding is actually the problem.
Here, make the following change to site_docs.css and see what you
think.
current:
a { line-height: 1.2em; }
replace this with:
li li { line-height: 1.2em; }
This leaves in place the 1.3em that's inherited from above for the
main lis, but their sub-items get a more cozy 1.2em. To me this
looks as it should.
Eric
On Dec 5, 9:23 am, Michael Bayer [EMAIL PROTECTED] wrote:
well we have no control over any of thatI don't know that Sphinx
search uses case insensitivity for full text searches.
On Dec 5, 2008, at 11:53 AM, Jon Nelson wrote:
The searching is a bit weird.
If I search for Adjacency I get no results. If I search for adjacency
(all lower case) I get results, the first of which has an upper-cased
Adjacency.
Otherwise they look nice and I'm sure will look nicer-yet as time
goes on!
--
Jon
--~--~-~--~~~---~--~~
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: SQLAlchemy Sphinx Documentation Preview
Forgot to add that I can't see much reason for links to be given a
line-height that would be any different from the text that surrounds
them -- at least not on the TOC page. That's why I felt free to scrap
the 'a' rule and put the 'li li' in the same spot. If the 'a' rule is
necessary for other pages then my suggestion could be an addition
instead of a replacement.
On Dec 5, 7:48 pm, Eric Ongerth [EMAIL PROTECTED] wrote:
Mike,
Gaetan's right -- I just viewed the site a day after you (Mike) said
that the li issue had been fixed, but they're still too widely
spaced for sure. There are several conflicting (well ok, inheriting/
overriding) settings of line-height across the various css files, and
it does not appear that padding is actually the problem.
Here, make the following change to site_docs.css and see what you
think.
current:
a { line-height: 1.2em; }
replace this with:
li li { line-height: 1.2em; }
This leaves in place the 1.3em that's inherited from above for the
main lis, but their sub-items get a more cozy 1.2em. To me this
looks as it should.
Eric
On Dec 5, 9:23 am, Michael Bayer [EMAIL PROTECTED] wrote:
well we have no control over any of thatI don't know that Sphinx
search uses case insensitivity for full text searches.
On Dec 5, 2008, at 11:53 AM, Jon Nelson wrote:
The searching is a bit weird.
If I search for Adjacency I get no results. If I search for adjacency
(all lower case) I get results, the first of which has an upper-cased
Adjacency.
Otherwise they look nice and I'm sure will look nicer-yet as time
goes on!
--
Jon
--~--~-~--~~~---~--~~
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: SQLAlchemy Sphinx Documentation Preview
Oh yeah, and in Main Documentation (at least) you have some ul class=simple lists nested inside of blockquote elements, which is resulting in some of your lists being much farther indented than others, without a good visual reason why. Seems like the difference could be eliminated. I sent new association_proxy docs via jek; hopefully you'll find them worthwhile in total or in part. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
