issues with the new Entity.set and to/from_dict
Jason R. Coombs
In 0.5.2, the __init__ and .set methods performed the same function:
for key, value in kwargs.items():
setattr(self, key, value)
My first question is, why didn't __init__() just call set()? Were you
looking forward to the changes in 0.6? Even in 0.6, should __init__
just call set()? Perhaps the answer lies in my second question.
Beginning with 0.6, set does something different. It attempts to
reassemble an object from a JSON-generated structure:
def set(self, **kwargs):
self.from_dict(kwargs)
Unfortunately, the from_dict method fails to set properties who's
property name does not match the column name:
class Attribute(Entity):
key = Field(String(256), colname='attribute_key')
new_attr = Attribute()
new_attr.set(key='foo') # fails to set key beginning in 0.6.
Perhaps to_dict and from_dict could be kept independent of .set,
maintaining backward compatibility.
Furthermore, I'm unsure the motivation for using column names instead
of entity properties, but I would suggest even using entity properties
for generating the JSON dicts. I'm not sure if this is feasible, but
from my perspective, one of the primary advantages of Elixir/
SQLAlchemy is that it abstracts underlying details such as the column
names so that more appropriate and consistent names can be used in the
application. The to/from_dict methods violate this abstraction, and I
believe that is why my app fails.
Is there perhaps a better way to implement the to/from_dict methods to
(a) better handle properties whose names differ from the column names
and (b) allow set to be backward compatible with 0.5?
I wanted to start with the discussion here. Let me know if I should
post any of these in the trac ticket system.
Regards,
Jason
Jonathan LaCour
> The new Entity.set in Elixir 0.6 breaks some of my projects.
Sorry to hear that (and sorry it took me so long to reply).
> In 0.5.2, the __init__ and .set methods performed the same
> function:
> for key, value in kwargs.items():
> setattr(self, key, value)
>
> My first question is, why didn't __init__() just call set()? Were
> you looking forward to the changes in 0.6? Even in 0.6, should
> __init__ just call set()? Perhaps the answer lies in my second
> question.
I believe that Gaetan made this change, and he won't be back from
his honeymoon until tomorrow. I suspect he'll probably need a little
time to get settled again.
> Is there perhaps a better way to implement the to/from_dict
> methods to (a) better handle properties whose names differ from
> the column names and (b) allow set to be backward compatible with
> 0.5?
>
> I wanted to start with the discussion here. Let me know if I
> should post any of these in the trac ticket system.
I think you are right after reviewing your reasoning. Go ahead and
open a ticket, and reply to this list when you've done so. Once
Gaetan gets back into the swing of things, we can have a discussion
about the reasoning for the original change, and see if we can come
up with a better solution before we release a new version.
Thanks for the heads up, and sorry for the late reply!
--
Jonathan LaCour
http://cleverdevil.org
Gaetan de Menten
<jonatha...@cleverdevil.org> wrote:
>
> Jason R. Coombs wrote:
>
>> The new Entity.set in Elixir 0.6 breaks some of my projects.
>
> Sorry to hear that (and sorry it took me so long to reply).
>
>> In 0.5.2, the __init__ and .set methods performed the same
>> function:
>> for key, value in kwargs.items():
>> setattr(self, key, value)
>>
>> My first question is, why didn't __init__() just call set()?
I can't find any good reason for that. It was just an oversight I suppose.
>> you looking forward to the changes in 0.6? Even in 0.6, should
>> __init__ just call set()?
Yes I think it should, but we should first make sure from_dict is a
superset of the "set" method functionality (which I thought it was).
>> Perhaps the answer lies in my second
>> question.
Indeed.
>> Is there perhaps a better way to implement the to/from_dict
>> methods to (a) better handle properties whose names differ from
>> the column names and (b) allow set to be backward compatible with
>> 0.5?
Yes, that should be the case IMO.
>> I wanted to start with the discussion here. Let me know if I
>> should post any of these in the trac ticket system.
Please do.
> I think you are right after reviewing your reasoning. Go ahead and
> open a ticket, and reply to this list when you've done so. Once
> Gaetan gets back into the swing of things, we can have a discussion
> about the reasoning for the original change, and see if we can come
> up with a better solution before we release a new version.
The reasoning was just to augment the set method with more
functionality. I just didn't realize it was not backward compatible
when I applied the patch from Paul Johnston. Should be fixable though.
Anybody want to try his luck at fixing this?
--
Gaëtan de Menten
http://openhex.org
Jason R. Coombs
take a quick stab at a patch and see what happens.
Jason
On Jun 13, 10:33 am, "Gaetan de Menten" <gdemen...@gmail.com> wrote:
> On Tue, Jun 10, 2008 at 4:12 PM, Jonathan LaCour
>