Thread: [PyPerSyst-Devel] Fwd: sandbox/gldnspud/fieldproblem ...
Brought to you by:
pobrien
Menu
▾
▴
pypersyst-devel
|
From: Matthew S. <gld...@us...> - 2004-06-21 17:12:34
|
def testFieldBuilder(self):
db = self.db
b = db.root._classes['Field'].txb_create()
b.new.name = 'foo'
db.execute(b.transaction())
The result of this test is as follows:
ERROR: testFieldBuilder (__main__.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test.py", line 23, in testFieldBuilder
b = db.root._classes['Field'].txb_create()
File "/home/gldnspud/p/PYTHONPATH/pypersyst/entity/entity.py", line
179, in txb_create
new = cls._SurrogateClass(attrs={})
File "/home/gldnspud/p/PYTHONPATH/pypersyst/entity/base.py", line 21,
in __init__
value = attrs[name]
KeyError: 'name'
I haven't thought through a solution to this yet, but here is my
understanding of the symptoms.
When a surrogate is created using the txb_create classmethod of an
entity class, the class returned by cls._SurrogateClass is a subclass of
pypersyst.entity.base.Entity
If a _fieldSpec is specified for the Entity class upon which the
surrogate is being created for, ...base.Entity.__init__ iterates through
all of the _fieldSpec items and tries to create field instances for
them, initializing them with the values passed in via the "attrs" argument.
The problem is though, with the surrogate created by txb_create, an
empty dictionary is passed in as "attrs", thus causing the KeyError
exception above.
I think I have a general idea of how to solve this problem based on what
I've done for 'Syst-o-matic so I will post a patch to fix this sometime
today.
|
|
From: Matthew S. <gld...@us...> - 2004-06-21 17:40:15
Attachments:
pypersyst-builder-field.patch
|
> I think I have a general idea of how to solve this problem based on what > I've done for 'Syst-o-matic so I will post a patch to fix this sometime > today. Attached is said patch. Comments in the patch make it pretty self-explanatory. Oh, and I was able to use the pop() method on a dictionary for the first time, to avoid wrapping something in a try/except block. That was fun :) |
|
From: Matthew S. <gld...@us...> - 2004-06-21 17:59:05
|
Matthew Scott wrote: > Attached is said patch. Hmm... not quite. Updated patch coming soon. |
|
From: Matthew S. <gld...@us...> - 2004-06-21 18:16:47
Attachments:
pypersyst-builder-field.patch
|
Matthew Scott wrote: > Matthew Scott wrote: > >> Attached is said patch. > > > Hmm... not quite. Updated patch coming soon. Pretty sure this one will do the trick. |
|
From: <po...@or...> - 2004-06-25 17:37:53
|
Matthew Scott <gld...@us...> writes: > Matthew Scott wrote: > > Matthew Scott wrote: > > > >> Attached is said patch. > > Hmm... not quite. Updated patch coming soon. > > Pretty sure this one will do the trick. My instincts are telling me that I'd rather not instantiate the fields themselves on a create builder. I think I'd prefer to have the ui constuct itself based on the attributes for the field class, rather than instantiate a field with a Null/None value, specialized flag, etc. I'll look into this more closely so we can discuss the alternatives. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Blog http://www.sum-ergo-cogito.com |
|
From: <po...@or...> - 2004-06-25 18:01:47
|
po...@or... (Patrick K. O'Brien) writes: > Matthew Scott <gld...@us...> writes: > > > Matthew Scott wrote: > > > Matthew Scott wrote: > > > > > >> Attached is said patch. > > > Hmm... not quite. Updated patch coming soon. > > > > Pretty sure this one will do the trick. > > My instincts are telling me that I'd rather not instantiate the fields > themselves on a create builder. I think I'd prefer to have the ui > constuct itself based on the attributes for the field class, rather > than instantiate a field with a Null/None value, specialized flag, > etc. > > I'll look into this more closely so we can discuss the alternatives. Having said that, I'm now thinking about the asymetry that would result -- update and delete surrogates would have field instances, but create surrogates would not. Yuck. So now I'm thinking that perhaps a lazy construction approach would be appropriate for field classes. So instead of Field.__init__() calling self.set(value), the value would not be passed as an argument to __init__, and the user of the field would have to call field.set(value) explicitly. That would allow us to constuct a field with no value, which is what you want for a create surrogate. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Blog http://www.sum-ergo-cogito.com |
|
From: Matthew S. <gld...@us...> - 2004-06-25 20:50:06
|
Patrick K. O'Brien wrote: >So instead of Field.__init__() calling self.set(value), the value >would not be passed as an argument to __init__, and the user of the >field would have to call field.set(value) explicitly. That would >allow us to constuct a field with no value, which is what you want for >a create surrogate. > > The reason I create the subclass on-the-fly was that it was a quick way to allow the None value to be set on a field in a Create surrogate. I agree that having this kind of ability in Field rather than hacked into Entity would be smarter though. Perhaps it already supports this and I didn't look closely enough :) I'll investigate and see what I discover. - Matthew |
|
From: Matthew S. <gld...@us...> - 2004-06-25 21:30:44
Attachments:
pypersyst-builder-field.patch
|
Is the attached patch closer to what you had in mind? It's smaller and simpler and probably more efficient :-) The changes it makes are: pypersyst.field.field.Field already had a _bypass attribute that could be set to True to keep __init__ from validating the value. __init__ now has a 'bypass' argument defaulting to None, that if set to something other than None will override the _bypass attribute. pypersyst.entity.base.Entity.__init__ now accepts a 'bypass' argument defaulting to None. If it is set to True or False, it is passed along to the field constructor which will act as described above. Additionally, if it is set to True, any field for which there is no corresponding value in 'attrs' will be given the value None. pypersyst.entity.entity.Entity.txb_create sets bypass=True when creating its surrogate instance. Any custom txb_create in someone's code would need to do this as well. Matthew Scott wrote: > Patrick K. O'Brien wrote: > >> So instead of Field.__init__() calling self.set(value), the value >> would not be passed as an argument to __init__, and the user of the >> field would have to call field.set(value) explicitly. That would >> allow us to constuct a field with no value, which is what you want for >> a create surrogate. >> > I agree that having this kind of ability in Field rather than hacked > into Entity would be smarter though. Perhaps it already supports this > and I didn't look closely enough :) I'll investigate and see what I > discover. |
Thanks for helping keep SourceForge clean.
X