[sqlalchemy] Re: relations with additional criteria

Hey, Michael Bayer wrote: [snip] For the next go-around here, assuming this is all still not working for you can you please provide an example of what the additional filter does exactly ? Oh, it was already working for me (with the hack as described with backref and such, earlier in

[sqlalchemy] Re: relations with additional criteria

Hey, Michael Bayer wrote: [snip] well that is the part of the use case I don't understand. Why the automagic aspect of it ? and if there are dozens of target tables that have similar attributes, why not reduce the workload in a more boring way, like one that just adds the attributes after

[sqlalchemy] Re: relations with additional criteria

Hey, Thanks very much for looking into this. I'm sorry I couldn't offer more specific suggestions earlier - my goal was just to start the thought process leading to such suggestions (also in myself), and at this point you're still a lot more familiar with this codebase than I am. :) I'm

[sqlalchemy] Re: relations with additional criteria

Hey, Michael Bayer wrote: Martijn Faassen wrote: Michael Bayer wrote: subclass RelationProperty fine, but don't get involved with overriding its internal _xxx methods. So: Override do_init() completely (not calling the super do_init()). no, call do_init(). def do_init(self

[sqlalchemy] Re: relations with additional criteria

Hey, Michael Bayer wrote: [snip] OK well I'm sure you noticed that RelationProperty was not designed to be subclassed. I would advise that your my_own_relation() function generate its own primaryjoin and secondaryjoin conditions which it passes as arguments to the relation(). Looking at

[sqlalchemy] Re: relations with additional criteria

Hey, Michael Bayer wrote: subclass RelationProperty fine, but don't get involved with overriding its internal _xxx methods. So: Override do_init() completely (not calling the super do_init()). Do something like: def do_init(self): self._get_target()

[sqlalchemy] relations with additional criteria

Hi there, The relation() logic lets you write an additional filter into a relation if you provide your own primaryjoin. The case I'm dealing with is a case where I want to take over the primaryjoin that is autogenerated by the RelationProperty object, but amend it with an extra filter. This

[sqlalchemy] Re: relations with additional criteria

Michael Bayer wrote: [snip] Whats missing here is the context. I want to define ORM relations in the mapper that I can access without having to do a manual join. Normally you'd do this: mapper(A, a_table, properties={ 'bs': relation(B , backref='a',

[sqlalchemy] Re: relations with additional criteria

Hey, Michael Bayer wrote: OK well I'm sure you noticed that RelationProperty was not designed to be subclassed. Yeah, my subclass isn't pretty. :) I would advise that your my_own_relation() function generate its own primaryjoin and secondaryjoin conditions which it passes as arguments to

[sqlalchemy] finding related objects

Hi there, I'm trying to figure out whether there's something in SQLAlchemy that lets me reliably get all the objects related to another: i.e. all children of a parent that (in the underlying record) have a foreign key relationship to the parent record. One way I've been trying to solve this

[sqlalchemy] Re: finding related objects

Hey, [finding related objects] One way I've come up with is this: m = object_mapper(model) for prop in m.iterate_properties: if isinstance(prop, RelationProperty): if prop.direction is ONETOMANY: for related in getattr(model, prop.key):

[sqlalchemy] Re: composite primary key problem

Hey, Michael Bayer wrote: the program works for me, I get: That's interesting. I've tested the script with Python 2.4, Python 2.5, and Python 2.6, with SQLAlchemy 0.5.5 and trunk. sqlite version is 3.4.2. I get the assertion error each time. The output I get when echo is True (on SA

[sqlalchemy] Re: making an instance read-only

Hey, phrrn...@googlemail.com wrote: I implemented a very crude flush/commit-time version of this today that disables all modifications. Michael suggested the use of connection_callable to provide fine-grained control of which engine to use for modifications. I haven't gone through all the

[sqlalchemy] Re: composite primary key problem

Hey, I now also tested the program with sqlite3 3.6.10: same problem. pysqlite2.5.5 is in use. Regards, Martijn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send

[sqlalchemy] Re: composite primary key problem

Hi there, I'm looking at the remove() method in sqlalchemy.orm.identify.WeakInstanceDict, as this is where the assertion error is raised. In the 'self' dictionary there is indeed an sqlalchemy.orm.state.InstanceState object with under the key (it's the only entry in the dictionary), but

[sqlalchemy] Re: making an instance read-only

phrrn...@googlemail.com wrote: You are correct: the code-snippet will cause an exception to be thrown when SA attempts to flush any changes. However, the connection callable is called *per-instance* and it is supposed to return the connection to use to perform the flush. Inside the callable,

[sqlalchemy] Re: composite primary key problem

Hey Michael, Cool that you managed to reproduce the issue. Michael Bayer wrote: and a potential fix is this: Index: lib/sqlalchemy/orm/session.py === --- lib/sqlalchemy/orm/session.py (revision 6289) +++

[sqlalchemy] making an instance read-only

Hi there, I'm investigating ways to make an ORM-mapped instance read-only, dependent the value of a particular attribute (database backed or not). If an object has a certain state, I want to prevent normal users from making a modification. Other objects connected to the same session should

[sqlalchemy] cloning ORM-mapped instances

Hi there, I'm looking into a reliable way to clone ORM-mapped instances, so that the clone, with some modifications, can be re-added to the database. I saw the following thread: http://groups.google.com/group/sqlalchemy/browse_thread/thread/6e162f9a74697a01/6396c677b2a87797#6396c677b2a87797

[sqlalchemy] composite primary key problem

Hi there, I'm experimenting with a composite primary key to see whether it might help implement a workflow system, where the primary key consists of an identifier (code) and a workflow status. I run into an error with the ORM (in 0.5.5 and trunk) when I modify part of the primary key (the

[sqlalchemy] Re: declarative, autoload and late binding to engine

Hi there, MikeCo wrote: I have an application that will need to bind to several different databases with the same structure. The databases to be accessed are not known at import time, that will be determined later while the application is running. I want to use declarative and autoload the

[sqlalchemy] Re: proposed extension to SessionExtension: after_bulk_operation

Hi there, Michael Bayer wrote: I would say it should be called in any case, rows or not, and the result object provided. Just provide a patch and we're GTG. Done. The patch is attached. I can commit it myself if it looks all right. I wonder if a before_ hook should be provided as

[sqlalchemy] proposed extension to SessionExtension: after_bulk_operation

Hi there, I've been using zope.sqlalchemy's integration with SQLALchemy and it's been working pretty well so far. Today however I ran into a snag when using session.query(..).delete(). While a query immediately after the delete showed no more objects, in the next transaction the objects

[sqlalchemy] Re: foreign key problem when using reflection and schemas

jason kirtland wrote: That should be working now in r5203. The reflection code was missing an edge case where an explicit schema= is the same as the connection's schema. Switching those to schema=None should work as intended if you need a workaround on a released version. Thanks a lot

[sqlalchemy] foreign key problem when using reflection and schemas

Hi there, I have a problem with foreign keys that seems to occur when I combine reflection and explicit schemas, in the context of MySQL. I've confirmed this problem with both rc2 and the trunk. It's best demonstrated with some failing code: Imagine the following MySQL database 'somedb':

[sqlalchemy] Re: tracking parents, names

Hey, Michael Bayer wrote: [snip] The part missing for me here is that bar, if its a MappedCollection, is not itself a mapped object in the same sense that foo or baz is. Keep in mind that a SQLAlchemy relation looks like: mapped class - collection - mapped class - (etc.) Yes,

[sqlalchemy] Re: tracking parents, names

Hey Michael, Thanks for the helpful answer. Michael Bayer wrote: [snip] (after I've reread the above two paragraphs many times it seems like the idea is that the target object doesn't know anything about the name of the relation in which its collected). The idea is that if the object

[sqlalchemy] Re: time to remove create_session?

Michael Bayer wrote: two things are needed: 1. the official way to create a Session when all you want is a Session, with no custom builder class or anything like that. It should not be grossly inconsistent with the default arguments of the current sessionmaker() call. 2. all the

[sqlalchemy] Re: overzealous check breaks doctesting

jason kirtland wrote: [snip] Could the check somehow be modified to still find true builtins but not those defined in a doctest? Sure. Any suggestions for an alternate check? Heh, no. It's quite difficult to come up with any alternative.. I wonder why doctest.DocFileSuite makes these

[sqlalchemy] Re: overzealous check breaks doctesting

jason kirtland wrote: Martijn Faassen wrote: jason kirtland wrote: [snip] Could the check somehow be modified to still find true builtins but not those defined in a doctest? Sure. Any suggestions for an alternate check? Heh, no. It's quite difficult to come up with any alternative.. I

[sqlalchemy] overzealous check breaks doctesting

Hi there, I'm writing a doctest in which I include a MappedCollection subclass. In my doctest, I create such a subclass:: class Foo(MappedCollection): ...pass Unfortunately later on, sqlalchemy.orm.collections.py has a check to determine whether Foo is really a builtin, and if so,

[sqlalchemy] Re: inconsistency in default arguments in trunk

Hi there, Michael Bayer wrote: [snip] I think the solution here at the least would be to remove prominent advertisement of create_session(). I'm not sure yet about deprecation/non-publicizing it. I still think its a useful function for ad-hoc creation of sessions with no extra

[sqlalchemy] Re: inconsistency in default arguments in trunk

[EMAIL PROTECTED] wrote: On Friday 20 June 2008 17:38:25 Michael Bayer wrote: [snip] move it in some convenience.py? together with other such non-mandatory but convenient shortcuts that most people would make in one form or another In my mind, create_session is actually not the shortcut or

[sqlalchemy] inconsistency in default arguments in trunk

Hi there, I just noticed on the trunk that on sessionmaker(), autocommit defaults to False, but autocommit defaults to True when you use create_session. autoflush is also True for sessionmaker, but for create_session, it's False. Finally autoexpire is True for sessionmaker, but False for

[sqlalchemy] Re: reusing or recreating engines

Hey, Michael Bayer wrote: On Jun 17, 10:04 am, Martijn Faassen [EMAIL PROTECTED] wrote: Hi there, A question came up when thinking about how to integrate SQLAlchemy with Zope. Is it all right to recreate an engine, once per session scope (thread, say), or is it better to reuse the same