the latest trunk does the same thing; it just wont try loading the column when you assign to it. workaround here is to either not remove your object from the session, ensure its in a session when you work with it, or just force a load of "c2" after a flush.
On Nov 2, 7:30 pm, Bruza <[EMAIL PROTECTED]> wrote: > Thanks for the reply. And you are right, column c2 has a default value > defined on it. > So, how do l configure SA to not automatically mark "c2" as > "deferred"? Sounds > like the latest trunk has a different implementation of this. Short of > getting the > latest 0.4.1, is there a way I can configure my current SA (version > 0.4.0)? > > Thanks again, > > Ben > > On Nov 2, 7:21 am, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > On Nov 2, 2007, at 12:41 AM, Bruza wrote: > > > > I am quite baffled by the "deferred loading" behavior on a class > > > member in the following code (see below). Looks like if I create an > > > object (t1) with some field (c2) having None as value, then after I > > > save, commit, and closed the object in a SQLAlchemy session, I cannot > > > update the c2 field. It will give me an InvalidRequestError error. > > > > However, if I loaded the same object (into t2) from DB (even though > > > t2.c2 field and attribute still having None as value), I can modify > > > t2.c2 field even after I commit, and close the session that associated > > > with t2. So, is this very confusing, or did I miss some of the reasons > > > in this behavior? > > > what youre not showing me here, that is the most crucial part of > > this, is what kind of column "c2" is. from what I can see, it > > appears that you have a SQL-side default set up on c2. when the > > object is inserted into the DB and you havent set a non-None value on > > "c2", the default will generate inline with the INSERT statement; SA > > then marks the column as "deferred" so that when next accessed, it > > will load the newly generated value. in the second case, you've > > loaded the object from the DB so "c2" just populates just like "c1" > > and its immediately available without a second SQL statement. > > > If you get the latest trunk or wait for version 0.4.1 (possibly this > > weekend), the behavior of "deferred" column attributes has changed > > such that you can set a new value without forcing a load of the > > previous value, so this particular error won't occur (trying to read > > "c1" when its deferred and theres no Session will still raise an > > error, however). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
