I am sorry that I use the wrong word. By getting around it, I mean instead of(this I believe is quite common coding style in python):
obj.attribute_a = something obj.attribute_b = something_else it has to be done using .set() It is the right way for multiple attibute update but I don't think it is a general usage pattern for python coding, thus the getting around it. Then there is the case where I need some intermediate variables to hold the result if I cannot have all the attributes at the same time. Again in python, it would be something like : obj.attribute_a = something ...some processing... obj.attribute_b = something_else because of processing It now needs to be changed to : _a = something ...some processing _b = something_else because of processing obj.set(attribute_a=_a,attribute_b=b) Now if I have quite a number of fields, the whole coding changed because of this behaviour. It ends up that I cannot write to "obj" unless I am very sure that everything is done. I think it really depends on how one use SQLObject. If it is used as DHH of RoR intended, i.e., the RDBMS is really just a backing store of object, everything should be fine. But it is still viewed and used(and shared) with other apps as RDBMS tables, this feature needs some time to get use to, at least know the consequence of each object attribute assignment. Ian Bicking wrote: > > I don't think it's just "get around it". .set() works, and I don't > think it looks bad or anything. SQLObject doesn't know what your future > intentions are for the object, it doesn't know if you will set one > attribute or 20. > > The alternative -- which is more of a "if it were so" alternative, not a > very practical alternative at this point -- is explicit saves. I don't > think that is any more concise or easy to use than .set(), since in both > cases you are defining a set of attributes enclosed in the scope of a > single update. .set() uses Python keyword syntax to do the enclosing, > explicit saves use a contract between the ORM and the programmer (the > "you better run save when you're finished!" contract). > > -- > Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
