Thread: [SQLObject] ._create() and .set()
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Oleg B. <ph...@ph...> - 2004-11-26 12:09:13
|
SQLObject._create() performs separation of values based on self._SO_plainSetters, creating "forDB" and "others", and calling self.set(**forDB). Is the separation really neccessary? self.set() does the same separation itself. Why not just pass all values to self.set()? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 15:50:26
|
Oleg Broytmann wrote: > SQLObject._create() performs separation of values based on > self._SO_plainSetters, creating "forDB" and "others", and calling > self.set(**forDB). > > Is the separation really neccessary? self.set() does the same > separation itself. Why not just pass all values to self.set()? I think you're right, there's no real reason for this split. It probably is left over from a (much) earlier time when the code didn't use .set while doing inserts (before _SO_creating). -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-29 21:36:34
|
On Mon, Nov 29, 2004 at 09:47:03AM -0600, Ian Bicking wrote: > Oleg Broytmann wrote: > >SQLObject._create() performs separation of values based on > >self._SO_plainSetters, creating "forDB" and "others", and calling > >self.set(**forDB). > > > > Is the separation really neccessary? self.set() does the same > >separation itself. Why not just pass all values to self.set()? > > I think you're right, there's no real reason for this split. It > probably is left over from a (much) earlier time when the code didn't > use .set while doing inserts (before _SO_creating). Well, there is a minor semantic difference. ._create() tests if all passed keywords arguments are actually columns. .set() does not test it. One can do self.set(noncolumn="value"), which results in assignment self.noncolumn="value", but can't do ATable(noncolumn="value"). Should we change the semantic of .set(), so it does not allow non-column keywords? In my opinion - yes, we should. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2004-11-29 21:51:11
|
Oleg Broytmann wrote: > On Mon, Nov 29, 2004 at 09:47:03AM -0600, Ian Bicking wrote: > >>Oleg Broytmann wrote: >> >>>SQLObject._create() performs separation of values based on >>>self._SO_plainSetters, creating "forDB" and "others", and calling >>>self.set(**forDB). >>> >>> Is the separation really neccessary? self.set() does the same >>>separation itself. Why not just pass all values to self.set()? >> >>I think you're right, there's no real reason for this split. It >>probably is left over from a (much) earlier time when the code didn't >>use .set while doing inserts (before _SO_creating). > > > Well, there is a minor semantic difference. ._create() tests if all > passed keywords arguments are actually columns. .set() does not test it. > One can do self.set(noncolumn="value"), which results in assignment > self.noncolumn="value", but can't do ATable(noncolumn="value"). > > Should we change the semantic of .set(), so it does not allow > non-column keywords? In my opinion - yes, we should. Yes, it's just an oversight that it doesn't check them. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Oleg B. <ph...@ph...> - 2004-11-30 13:05:16
|
On Mon, Nov 29, 2004 at 03:47:47PM -0600, Ian Bicking wrote: > > Well, there is a minor semantic difference. ._create() tests if all > >passed keywords arguments are actually columns. .set() does not test it. > >One can do self.set(noncolumn="value"), which results in assignment > >self.noncolumn="value", but can't do ATable(noncolumn="value"). > > > > Should we change the semantic of .set(), so it does not allow > >non-column keywords? In my opinion - yes, we should. > > Yes, it's just an oversight that it doesn't check them. Commited. This is a big change, so I spent more time testing it. I found I need a special treatment for inheritance. PS. Also I made a minor optimization: - extra = dict(filter(f_not_column, kw.items())) - kw = dict(filter(f_is_column, kw.items())) + items = kw.items() + extra = dict(filter(f_not_column, items)) + kw = dict(filter(f_is_column, items)) From time to time I will do some code cleanup and optimizations. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |