On Apr 29, 3:48 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Apr 29, 2007, at 7:10 AM, Martin Aspeli wrote:
>
> > Essentially, I'm dealing with a framework that has a storage layer
> > abstraction which is a little broken. It asks the storage to save
> > values
> > one-by-one, and there is no well-defined way to know when it's done
> > saving values. Previous attempts at SQL integration fell down on
> > things
> > like NOT NULL constraints, because they would essentially issue one
> > UPDATE statement for each column (well, an INSERT on the first one).
>
> im not sure what you mean by "it asks the storage to save one by
> one", if its just a matter of the schema design having circular-row
> relationships (i.e. cant just INSERT x and then INSERT y because they
> have foreign key constraints to each other), there is a relationship
> flag called "post_update" which is intended to make these possible.
Sorry, I probably didn't explain myself very well. The problem is not
in the database. I have a web application framework which generates
forms, and which has a storage abstraction layer which descides where
the form values are saved after the form has been submitted and
validated. I'd like to use SQLAlchemy to write such a storage layer
which stores the value in any SQL database.
When the user saves a form, each form field is saved one-by-one. That
is, the storage layer is told "save falue foo" and then later "save
value bar". These calls are isolated, so the storage layer doesn't
know when the form submit handler is finished saving values.
Therefore, my idea is to construct a mapper object lazily (on the
first form field) and attach it to a session immediately (with
session.save(), I presume). As the other save-field events come in,
I'll update the object property-by-property. At the request boundary,
I can make sure the session is flushed.
> > I guess what I'm after is a way to attach a "partial" object to a
> > session, and them modify it. I can see that working if SA doesn't
> > clone
> > objects in the session, i.e. my object references still point to the
> > thing in the session and SA doesn't attempt to validate the object as
> > soon as it's saved in the session.
>
> theres no cloning going on, you can flush() away any number of times.
I'd only flush once, I think. However, if I can save once, the modify
the object I just saved any number of times, and then flush at some
later point, that'd work I think.
Martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
