I did this in one of my previous projects. what I did was to make a python module, with the right SQLAlchemy includes and all the mapper objects. what I did not do is connecting to the database (it makes the class module database independent) What it does is it implements the iCal standard, it can read iCal files and export iCal files.
in one occasion it is being used by a CalDav server (completely written in python) and of course it needs to be interacting with the database. in the other occasion it is being used as a man-in-the-middle between an CRM application (with its own calendar) and Microsoft Exchange, in that case the class module is being used as a conversion utility and the "data" is actually never ever put into a database. It has both relationships and backrefs and works fine in both occasions. Let me know if you have any trouble, I use SQLalchemy a lot for handling data without saving it to a database. SQLAlchemy works fine when no database connection is present.... Martijn On Oct 27, 2010, at 5:41 PM, Michael Bayer wrote: > > On Oct 27, 2010, at 11:31 AM, Michael Elsdörfer wrote: > >> I have a mapper-based data model that uses relationships() >> extensively. In one particular instance, to implement a sort of >> "preview" feature, I'd like to work with a set of instances of my >> model class without saving them to the database, i.e. without adding >> them to the session. So I'm not calling session.add() for the objects >> I newly create, but if such a preview object as a relationship with >> another, existing object (i.e. with a session state of "Persistent"), >> then when the new and the existing objects are connected through that >> relationship, the latter is marked as dirty, causing both to be saved. >> >> Solutions that I've come up with so far: >> * Manually call expunge() on the preview objects >> * Set the proper cascade-settings for the relationships. >> >> Both I'm not entirely fond of; in particular, the latter prevents me >> from using the cascades I really want in all other cases. >> >> Is there a better way to deal with this? > > there's a new flag on relationship() called "cascade_backrefs". It prevents > save-update cascade from occurring for backrefs - in other words, the > save-update cascade moves only left to right. > > So if you were to say my_transient_object.some_related = some_related, if > "some_related" were in the Session, it would not cascade > "my_transient_object" in. > > We are possibly going to make this the default in 0.7. > > An example of the flag is at > http://www.sqlalchemy.org/docs/orm/session.html#cascades . > > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To post to this group, send email to sqlalch...@googlegroups.com. >> To unsubscribe from this group, send email to >> sqlalchemy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sqlalchemy?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
