[sqlalchemy] Re: Mapped class and c attribute in 0.5
Michael Bayer escreveu: in 0.5, the attributes on classes vs. the columns on Tables are very different beasts now. Got bitten by this too; I'm using MappedClass.c.keys() to serialize all attributes of a class but don't want to write out every field name. Should I use self._sa_class_manager.keys() instead? items = dict() for field in self._sa_class_manager.keys(): items[field] = getattr(self, field) Is there a simpler way, perhaps? Thanks, -- Luis Bruno --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Mapped class and c attribute in 0.5
On Jul 9, 2008, at 12:10 PM, Luis Bruno wrote:
Michael Bayer escreveu:
in 0.5, the attributes on classes vs. the columns on Tables are very
different beasts now.
Got bitten by this too; I'm using MappedClass.c.keys() to serialize
all
attributes of a class but don't want to write out every field name.
Should I use self._sa_class_manager.keys() instead?
items = dict()
for field in self._sa_class_manager.keys():
items[field] = getattr(self, field)
Is there a simpler way, perhaps?
obj.__dict__ is available as always for reading, I'd think thats the
easiest way to get at current object state.
items = dict([(k, v] for k, v in self.__dict__.iteritems() if not
k.startswith('_')])
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Mapped class and c attribute in 0.5
Michael Bayer escreveu: Luis Bruno wrote: items = dict() for field in self._sa_class_manager.keys(): items[field] = getattr(self, field) Is there a simpler way, perhaps? obj.__dict__ is available as always for reading, I'd think thats the easiest way to get at current object state. True. I had been using .c.keys() to get database-only attributes because I have some extra methods and attributes . I'll use a '_' prefix as you suggested. Thank you, -- Luis Bruno --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Mapped class and c attribute in 0.5
On Jun 25, 2008, at 10:48 AM, Huy Do wrote: Hi, I read in the 0.5 release notes that the c attribute was no longer necessary when doing queries using the mapped class, but I did not see it mentioned that the c attribute was removed all together. It's just that I've been using the c attribute in my Mapped classes to access the database/table metadata and now all my code will need to be changed to use the table.c attribute instead. Was there a reason for removing the c attribute from mapped classes altogether ? in 0.5, the attributes on classes vs. the columns on Tables are very different beasts now. Its not at all the same thing if you say: sess.query(MyClass.id, MyClass.name) vs. sess.query(mytable.c.id, mytable.c.name) since in the former case, we know that we are dealing with the MyClass mapper; in the latter case, we're not. The behavior of things like join(), polymorphic loading, other options, etc. are completely different - in the case of joined table inheritance it's dramatically different, where Subclass.id and subtable.c.id are literally different columns. So we really can't have a casual .c. attribute hanging around on classes with the new behavior; the user needs to be very explicit when choosing between MyClass.attr vs. table.c.attr. That said, you can retroactively add your .c. attribute using a MapperExtension that implements instrument_class(), and assigns the c attribute from the table to the class. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Mapped class and c attribute in 0.5
Michael Bayer wrote: On Jun 25, 2008, at 10:48 AM, Huy Do wrote: Hi, I read in the 0.5 release notes that the c attribute was no longer necessary when doing queries using the mapped class, but I did not see it mentioned that the c attribute was removed all together. It's just that I've been using the c attribute in my Mapped classes to access the database/table metadata and now all my code will need to be changed to use the table.c attribute instead. Was there a reason for removing the c attribute from mapped classes altogether ? in 0.5, the attributes on classes vs. the columns on Tables are very different beasts now. Its not at all the same thing if you say: sess.query(MyClass.id, MyClass.name) vs. sess.query(mytable.c.id, mytable.c.name) since in the former case, we know that we are dealing with the MyClass mapper; in the latter case, we're not. The behavior of things like join(), polymorphic loading, other options, etc. are completely different - in the case of joined table inheritance it's dramatically different, where Subclass.id and subtable.c.id are literally different columns. So we really can't have a casual .c. attribute hanging around on classes with the new behavior; the user needs to be very explicit when choosing between MyClass.attr vs. table.c.attr. That said, you can retroactively add your .c. attribute using a MapperExtension that implements instrument_class(), and assigns the c attribute from the table to the class. Michael, Thanks for the suggestion. Is there any metadata on the MyClass.id field at all ? like which column it's mapped too ? Lucky for me, I don't use any of the advanced SA features like inheritance and polymorphic stuff, so usually my MyClass.id is the same as my mytable.c.id (in the old SA). Thanks again, Huy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
