Now i was doing both, but you're right, i can remove the default from the column definition, and just initialise the object with the default in __init__ (from metadata i created elsewhere, but will remain available). Setting the default ASAP (on object creation) seems like the way of least surprise and it's not hard to do, as Wichert mentioned.
Thanks again, Michael, my code improves ... Lars On Saturday, July 13, 2013 10:59:08 PM UTC+2, Michael Bayer wrote: > > > On Jul 13, 2013, at 3:21 PM, Lars van Gemerden > <[email protected]<javascript:>> > wrote: > > > Just trying to help; i am not sure, but what you might also consider is > to initialise attributes (or on first access) with a default if a default > value as Column argument is given (i am already doing this in my own code) > and also reset to this default in case of del, but maybe there are > disadvantages. > > I can see why that might be reasonable, but at the same time the "default" > for Column is at the level of Core; the "default" could be a Python > callable, and this callable could be relying upon the fact that it is > invoked within the context of executing the INSERT statement. By pulling > out the Core-level "default" upon attribute access and just populating at > the ORM level means we bypass the Core in doing its normal job with > "default", which violates ..... there's a term for this I can't recall, but > the idea is, "A does job X using mechanism P" therefore if, based on some > very non-deterministic system, once in awhile "B does job X using mechanism > Q" instead, it makes the code much harder to understand and debug. So > to really do it this way, the contract of "default" in terms of the ORM > would need to be modified completely, such that *all* Column "default" args > are applied at the ORM level. But even then, your Column() is still > behaving in two different ways based on if you use Session.add() or > engine.execute(insert()). > > The original intent of "default" for Column is that it acts exactly like > "server_default", except it runs on the Python side for the case that your > schema wasn't created with this default, or the functionality of your > default is not supported by the database. But otherwise, just like a > "server_default", the value is None on the Python side until the INSERT > occurs. > > Really, a better solution here would be an ORM-level "default", that's > what you've implemented anyway. > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
