Michael,
Thanks.
It was reflecting fine, it's just that nobody ever put the foreign key
constraints into the DDL (what would MySQL do with them anyway).
I solved my problem by just using
relation(OtherTableObject, primaryjoin=ThisTableObject.c.id ==
OtherTableObject.c.id)
When I use append_ite
foreign keys should be reflected (if thats what youre asking). if
you have a mysql table thats not reflecting properly, feel free to
send its DDL on over.
if you want a column to be a foreign key to several other tables,
youre better off appending ForeignKeyConstraint objects to the end of
Today I had the following solution against SQLAlchemy's trunk while
dealing with a MySQL database. This MySQL 4.0 database has the gall to
have upper case letters in its table names, and it returns the
lower_case_table_names variable as the string '0'.
No foreign key relationships were ever specif
Gary Bernhardt wrote:
> On 9/8/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
> It might be nice if SA complained about modified PKs. It sure would've
> saved me a lot of time. :) Of course, it may be undesirable or
> impractical
> for reasons I'm not aware of.
this actually should be pretty eas
On 9/8/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
you've found a slightly confusing example that basically is answered byissue #1 on the SQLAlchemy FAQ at http://www.sqlalchemy.org/trac/wiki/FAQ
Thanks for the quick response! This makes perfect sense. I've read the FAQ, but for some reason it ap
you've found a slightly confusing example that basically is answered by
issue #1 on the SQLAlchemy FAQ at http://www.sqlalchemy.org/trac/wiki/FAQ
.
SA's mapper works from the assumption of immutable primary keys (however,
like the faq says, you can change primary keys if you want, just SA's ORM
n
I only started learning SQLAlchemy a few days ago, so I apologize in advance if I'm just confused. :)I've been thinking that I just didn't understand SQLAlchemy, but I now think I might be running into a nasty bug. I've generated two simple tests (attached) that show the problem (one passes; the o
+1 QOTWOn 8/9/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
i for one welcome rabbits in my orderedproperties.anyway, patched in r1773, thanks.On Aug 9, 2006, at 2:10 PM, Kapil Thangavelu wrote: from sqlalchemy.util import OrderedProperties
>>> props = OrderedProperties()>>> 'rabbit' in props:>
i for one welcome rabbits in my orderedproperties.
anyway, patched in r1773, thanks.
On Aug 9, 2006, at 2:10 PM, Kapil Thangavelu wrote:
>
>>> from sqlalchemy.util import OrderedProperties
>>> props = OrderedProperties()
>>> 'rabbit' in props:
> True
>
> patch for OrderedProperties
>
> Index: ut
>> from sqlalchemy.util import OrderedProperties
>> props = OrderedProperties()
>> 'rabbit' in props:
True
patch for OrderedProperties
Index: util.py
===
--- util.py (revision 1770)
+++ util.py (working copy)
@@ -121,6 +121,
This one time, at band camp, Michael Bayer wrote:
>before even running it I added this:
>
>print class_mapper(Submission).props['people'].primaryjoin
>print class_mapper(Submission).props['people'].secondaryjoin
>print class_mapper(Submission).props['people'].lazywhere
>print class_mapper(Person).p
before even running it I added this:
print class_mapper(Submission).props['people'].primaryjoin
print class_mapper(Submission).props['people'].secondaryjoin
print class_mapper(Submission).props['people'].lazywhere
print class_mapper(Person).props['submissions'].lazywhere
which revealed the issue:
Hey,
I've got some interesting behaviour on a slightly obtuse schema: I map a
Person onto two tables, 'account' and 'person', which store login details
and personal details, respectively. I then have a many-many join onto a
submission table, which contains details about papers.
Attached is a th
Julien -
can I get a full test case on this one ? theres a "AND
invasives.status = 1" in the join condition for the queries you are
showing me but that is not in the mapper setup you are showing me;
when I run a basic many-to-many with three tables I cannot reproduce
the error you are get
thats a bug.
turning off the eager loading will definitely fix it for now. a
slightly longer shot would be to use a literal as your order by,
"order_by='habitats.id'", but im going out on a limb with that one.
seems like the "aliasing" step of the eager loading is clobbering the
ORDER BY
Hello again,
Another strange thing I noticed today. Here is a part of my tables /
mappers :
invasive_habitats = Table('invasive_habitats', meta,
Column('invasive_id', Integer, ForeignKey('invasives.id'),
primary_key=True),
Column('habitat_id', Integer, ForeignKey('habitats.id'),
primary_
Hey,
I've got an interesting bug using the key attribute to change column names,
only on a DateTime type column, in sqlite.
Attached is a sample program that highlights it.
t1 is the table definition, the way I want to do it (i.e. I have a schema I
can't change, but for consistency in the upper
stick "correlate=False" in the max_date select() statement, it needs
a hint to not do that. you might want to also just say max_date =
max_date.alias('maxtab') which also should prevent it from correlating.
On Jun 8, 2006, at 2:34 PM, facundo chamut wrote:
> max_date=select([func.max(tab.c.d
max_date=select([func.max(tab.c.date)])>>> SELECT max(tab.date) FROM tabs=tab.select(tab.c.fecha==(max_fecha))>>>SELECT a_lot_of_stuff FROM tab WHERE tab.date = (SELECT max(tab.date
)) note the lack of a FROM part in the last statement.what am I missing?Thanks,-Facundo.
___
On Jun 7, 2006, at 3:10 AM, Sandro Dentella wrote:
> needed. (Btw: I'd really like to see the error raised when
> autoloading if
> the table does not exist, as recently proposed)
this was implemented in changeset 1589. mysql was already doing it
since the "describe" command throws an except
On Tue, Jun 06, 2006 at 12:15:24PM -0600, William K. Volkman wrote:
> On Tue, 2006-06-06 at 10:43, Michael Bayer wrote:
> > On Jun 5, 2006, at 11:50 PM, William K. Volkman wrote:
> >
> The fact that they've gone to the trouble to constrain certain
> fields to only be visible to the table owner
> i
OK well your argument basically appears to be "table reflection is
dumb, nobody should ever use it" and therefore "information_schema
shouldnt care about supporting it".
regarding reflection, as it turns out i am not a huge fan of it
either, as its true constraints can be turned off in datab
Hello, J. Random programmer here,
William K. Volkman wrote:
> Once an application is designed, the tables and columns don't change
> much, why do they need to be able to queried?
Because the programmer is lazy and doesn't want to repeat the list of
columns (and types) both in the database schem
On Tue, 2006-06-06 at 10:43, Michael Bayer wrote:
> On Jun 5, 2006, at 11:50 PM, William K. Volkman wrote:
>
> > Users of the tables, particularly web applications, are
> > only granted the minimum SQL privileges necessary for their
> > tasks. The capability to execute DDL operations would
> > sp
On Jun 5, 2006, at 11:50 PM, William K. Volkman wrote:
> Users of the tables, particularly web applications, are
> only granted the minimum SQL privileges necessary for their
> tasks. The capability to execute DDL operations would
> specifically be prohibited. It is only in small personal
> typ
On Tue, Jun 06, 2006 at 02:22:39PM +0200, Sandro Dentella wrote:
> On Mon, Jun 05, 2006 at 07:32:52PM -0400, Michael Bayer wrote:
> >im on 8.0.4 here and it performs like crap. not sure if the "primary key
> >with a different user" bug (ticket 71 in trac) is with the 8 series as
> >wel
On Mon, Jun 05, 2006 at 07:32:52PM -0400, Michael Bayer wrote:
>im on 8.0.4 here and it performs like crap. not sure if the "primary key
>with a different user" bug (ticket 71 in trac) is with the 8 series as
>well.
It's working ok with pg8.1 while it's not with 7.4.
sandro
*:-)
--
On Sat, 2006-06-03 at 13:43 -0400, Michael Bayer wrote:
> we've had a lot of issues with Postgres and using
> information_schema. whereas MySQL's information_schema support was
> pointless, Postgres mostly works, but performs very slowly unless you
> VACUUM your database every hour. we've h
im on 8.0.4 here and it performs like crap. not sure if the "primary key with a different user" bug (ticket 71 in trac) is with the 8 series as well.On Jun 5, 2006, at 4:32 PM, Jonathan Ellis wrote:On 6/3/06, Michael Bayer <[EMAIL PROTECTED]> wrote: we've had a lot of issues with Postgres and usin
in this line:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/engine/default.py#L26
shouldn't the class be exceptions.InvalidRequestError ?
___
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.
we've had a lot of issues with Postgres and using
information_schema. whereas MySQL's information_schema support was
pointless, Postgres mostly works, but performs very slowly unless you
VACUUM your database every hour. we've had reports of primary keys
not being reflected for tables acro
There is something wrong with my 7.3.x database. The primary key is
not shown in information_schema.table_constraints while it is in the
table definition.
So this is not a bug of SA but maybe that of postgres.
On 6/3/06, Yuan HOng <[EMAIL PROTECTED]> wrote:
I've found out that when I try to aut
I've found out that when I try to autoload the table metadata from
Postgres 7.3.x databases, the primary key column is not correctly
detected by SA. The loaded table will be without primary key.
But with Postgres 8.x, primary key is correctly set for the table
automatically reflected from the dat
thanksin fact i used something less documented, "column._label",
since that includes logic for truncating the size down if over 30
chars in length. this is committed to 0.1 and 0.2.
On May 23, 2006, at 4:12 AM, Sean Cazzell wrote:
I'm seeing the same problem with postgresql and SA 0.2.
I'm seeing the same problem with postgresql and SA 0.2. Currently
indexes are getting named like "ux_column/ix_column" - is there any
reason this couldn't be changed to "ux_table_column"?
I've made the change to schema.py and it works for me. Attached diff is
for the 0.2 branch.
Sean Cazzell
if youre working with 0.2, ive committed some big changes today
partially in response to this issue, including a unit test that tests
the ability to override columns and have them propigateyou might
want to try it and see if you have better luck.
On May 18, 2006, at 11:14 AM, Marty McFl
absolutely. inheritance is still quite buggy, this will all be fixed
eventually (in 0.2).
On May 18, 2006, at 11:14 AM, Marty McFly wrote:
Hi,
Thanks for the fast answer, Mike! Another small, maybe related
question. Let's say that I override the column names in the mapper
of my base cl
Hi,
Thanks for the fast answer, Mike! Another small, maybe related question. Let's
say that I override the column names in the mapper of my base class, for
example 'body' instead of 'text', like this:
TextItem.mapper = mapper(TextItem, text_items,
properties = {'body' : tex
its because your post mapper is using joined table inheritance, i.e.
joining text_items to posts. so the primary key of "text_items JOIN
posts on text_items.id==posts.id" is a composite of "text_items.id,
posts.id". So.it considers the primary key of Post id #1 to be
this:
m
Hi everybody, here's a small script using mapper inheritance that fails on my
machine (SQLAlchemy 0.1.7, Python 2.4.2). The following line at the end of the
script below causes an error:
firstTry = Post.mapper.get(1)
Whereas the next line works fine
secondTry = Post.mapper.get_by(id=1)
Is it a
The following code doesn't work when sqlite is used as a backend; the unique
index on both tables is created with the same name.
This is SQLAlchemy 0.1.7 with pysqlite2 2.2.2.
from sqlalchemy import *
a = Table('a',
Column('id', Integer, primary_key=True),
Column('name', String, unique=True)
)
thanks, this is committed in 1392
On May 4, 2006, at 1:07 AM, HD Mail wrote:
Hi,
"Having" clause needs to be before "Order by" for postgresql.
Index: ansisql.py
===
--- ansisql.py (revision 1387)
+++ ansisql.py (working copy)
Hi,
"Having" clause needs to be before "Order by" for postgresql.
Index: ansisql.py
===
--- ansisql.py (revision 1387)
+++ ansisql.py (working copy)
@@ -371,15 +371,15 @@
if group_by:
text += " GROUP BY " + gr
I am pleased to announce that I found and fixed this bug, and
actually got it to save a Group and User object, properly inheriting
from the Principal on both sides. I had not tested inheritance this
deeply before so I wasnt quite sure if it was going to work :).
checked into rev 973, patc
awesome, thank you. feel free to use the sample code as you wish.
cheers,
-kapil
Michael Bayer wrote:
I am pleased to announce that I found and fixed this bug, and actually
got it to save a Group and User object, properly inheriting from the
Principal on both sides. I had not tested inherita
hi,
i'm new to sqlalchemy, so far it seems really nice, by far the best
opensource orm in python, i ran into a problem though trying to model
a user system, with users and groups subclassed from principals, and a
many to many relation between users and groups. i have the following
code, attach
do you have a test case for this ? the proxy_engine unit tests all pass
(i.e. lets add this failure case as well).
Im not sure how "object.getattr(self, "__dict__")" changes anything vs.
self.__dict__ (since the __getattr__ should only be called for
non-existent attributes), or how this error is
I got this error after updating sqlalchemy today:
File "/Users/dmiller/Code/PyOE/src/orderentry/model.py", line 394,
in ?
assign_mapper(Value, value, properties=dict(alias=sa.relation
(Alias)))
File "/Users/dmiller/Code/SQLAlchemy/lib/sqlalchemy/mapping/
__init__.py", line 114, in ass
dmiller wrote:
> I'm not sure which is preferable, but it makes more sense to
> explicitly define the Address.mapper first. I would recommend
> deprecating use of the second positional argument (i.e. table) of
> "relation" to avoid this confusion.
in fact this is probably going to happen (i.e. dep
The following example code in the online documentation is confusing:
http://www.sqlalchemy.org/docs/index.myt?
paged=no#datamapping_relations_backreferences
User.mapper = mapper(User, users, properties = {
'addresses' : relation(Address, addresses, backref='user')
}
)
u = User(...)
..
nah it works, its essentially decorating the execute() process of the
db engine. The test suite hands it a list of SQL statements and
parameter lists to verify, and the list is set as an attribute on the
test wrapper, which it pops from each time a new statement comes in.
when the test is
I've been looking into SQLAlchemy's test suite, and I think I've found
a bug in the test suite, which may be causing some tests not to be
run.
In test/testbase.py, the EngineAssert class has a post_exec() function
that looks like it's supposed to run through a list of assertions and
check each one
2006/1/6, limodou <[EMAIL PROTECTED]>:
> 2006/1/6, Michael Bayer <[EMAIL PROTECTED]>:
> >
> > err Im not getting these resultsare you on the latest SVN checkout ?
> >
>
> no, I'll update from svn and try again.
>
I'm sorry, it was my fault, this time the test is ok!
Thanks a lot!
--
I like p
2006/1/6, Michael Bayer <[EMAIL PROTECTED]>:
>
> err Im not getting these resultsare you on the latest SVN checkout ?
>
no, I'll update from svn and try again.
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
-
err Im not getting these resultsare you on the latest SVN checkout ?
limodou wrote:
> Here is a test:
>
> from sqlalchemy import *
> import datetime
>
> sqlite_engine = create_engine('sqlite://filename=:memory:', echo=True)
>
> a = Table('a', sqlite_engine,
> Column('id', Integer, primar
not surprising, just reworked that code this weekend.
ill have to add some more unit tests for this one.
limodou wrote:
> Here is a test:
>
> from sqlalchemy import *
> import datetime
>
> sqlite_engine = create_engine('sqlite://filename=:memory:', echo=True)
>
> a = Table('a', sqlite_engine,
>
Here is a test:
from sqlalchemy import *
import datetime
sqlite_engine = create_engine('sqlite://filename=:memory:', echo=True)
a = Table('a', sqlite_engine,
Column('id', Integer, primary_key = True),
Column('name', String(4)),
Column('age', Integer),
)
a.create()
class A(object):
57 matches
Mail list logo