Thread: [SQLObject] Namespace pollution
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Edmund L. <el...@in...> - 2003-06-01 07:35:46
|
The way SO does things is quite nice. I do like the use of metaclasses to add in new methods as a result of joins. But, there needs to be a way to inspect the objects to see what methods and attributes have been automagically added, I think. I'm just speculating--because I haven't had the problem yet--that it could be quite easy to accidentally over-ride an automagically added method/attribute. Particularly if you've got a lot of classes, or wrote them a long time ago, or somebody else wrote them. In which case, it isn't at all obvious the methods/attributes of each object are. ...Edmund. |
From: Ian B. <ia...@co...> - 2003-06-03 07:13:25
|
On Sun, 2003-06-01 at 02:35, Edmund Lian wrote: > The way SO does things is quite nice. I do like the use of metaclasses > to add in new methods as a result of joins. But, there needs to be a way > to inspect the objects to see what methods and attributes have been > automagically added, I think. > > I'm just speculating--because I haven't had the problem yet--that it > could be quite easy to accidentally over-ride an automagically added > method/attribute. Particularly if you've got a lot of classes, or wrote > them a long time ago, or somebody else wrote them. In which case, it > isn't at all obvious the methods/attributes of each object are. Hmm... well, there are some private variables that hold information, like _SO_columnDict, in addition to the public _columns and _joins (poor naming aside). There's nothing very public at this point. Like with most of these things, I don't want to commit to anything until I know how it's *really* going to be used -- mostly to design the interface more appropriately. Ian |
From: Edmund L. <el...@in...> - 2003-06-06 16:51:12
|
I notice that when alternateID=True, and the associated .byWhatever() selection is performed, a SQLObjectNotFound exception is raised rather than None or [] being returned. However, when a normal .select() method is used, [] is returned. Does this seem a bit inconsistent? I'm thinking that with a .select(), one expects a list, so an empty list for no result makes sense. Similarly, with a .byWhatever(), one expects an object, so perhaps None for no result makes more sense than an exception? ...Edmund. |
From: Ian B. <ia...@co...> - 2003-06-06 18:56:11
|
On Fri, 2003-06-06 at 11:51, Edmund Lian wrote: > I notice that when alternateID=True, and the associated .byWhatever() > selection is performed, a SQLObjectNotFound exception is raised rather > than None or [] being returned. However, when a normal .select() method > is used, [] is returned. > > Does this seem a bit inconsistent? I'm thinking that with a .select(), > one expects a list, so an empty list for no result makes sense. > Similarly, with a .byWhatever(), one expects an object, so perhaps None > for no result makes more sense than an exception? No, I think SQLObjectNotFound is right. .byWhatever() is analogous to normal class instantiation, not selection. NULL references do get resolved to None, but those are explicit references in the database -- the analog of a join with a NULL reference (which doesn't throw an exception) would be a call like SomeObject.byWhatever(None), which isn't sensical. Ian |
From: Edmund L. <el...@in...> - 2003-06-06 19:35:29
|
Ian Bicking wrote: > No, I think SQLObjectNotFound is right. .byWhatever() is analogous to > normal class instantiation, not selection. Ah, OK, this makes sense, thanks. ...Edmund. |
From: Edmund L. <el...@in...> - 2003-06-09 06:35:07
|
Ian Bicking wrote: > On Sun, 2003-06-01 at 02:35, Edmund Lian wrote: > >>The way SO does things is quite nice. I do like the use of metaclasses >>to add in new methods as a result of joins. But, there needs to be a way >>to inspect the objects to see what methods and attributes have been >>automagically added, I think. [ snip ] > Hmm... well, there are some private variables that hold information, > like _SO_columnDict, in addition to the public _columns and _joins (poor > naming aside). There's nothing very public at this point. Like with > most of these things, I don't want to commit to anything until I know > how it's *really* going to be used -- mostly to design the interface > more appropriately. I think the most confusing thing for me right now is keeping track of the new methods and attributes that have been added to a class as the result of a join. Example: class Dog(SQLObject); _columns = [ Col("name"), Col("personId", foreignKey="Person")] _joins = [ MultipleJoin("Flea"), RelatedJoin("Friend")] When I look at this class definition some time after I've written it, I have to consciously remember that the class actually has: (1) The attributes "name" and "personId" (2) The implied attribute "person" (3) The implied attribute "fleas" (4) The implied attribute "friends" (5) The implied method addFriend I know the information is there in the class definition, but it isn't immediately obvious. One has to scan and interpret the definition to figure out what's there. It becomes harder when the class definition gets longer or more complex. When I wrote the message, I was thinking of this problem and said to myself: "wouldn't it be nice if I could just instantiate the object and ask it what attributes and methods it had". So I did a obj.__dict__ and found out that I could not. There must be some way to introspect the object to get this info... just haven't figured out how yet. ...Edmund. |
From: Ian B. <ia...@co...> - 2003-06-09 06:41:46
|
On Mon, 2003-06-09 at 01:34, Edmund Lian wrote: > Example: > > class Dog(SQLObject); > _columns = [ > Col("name"), > Col("personId", foreignKey="Person")] > _joins = [ > MultipleJoin("Flea"), > RelatedJoin("Friend")] The new style (which is explained in the documentation I haven't quite finished) is better in this regard: class Dog(SQLObject): name = Col() person = ForeignKey('Person') fleas = MultipleJoin('Flea') friends = RelatedJoin('Friend') addFriend/removeFriend is still implied. Perhaps if I make the join (friends) more powerful it will alleviate even this, so you'd do: aDog.friends.add(aPerson) > When I wrote the message, I was thinking of this problem and said to > myself: "wouldn't it be nice if I could just instantiate the object and > ask it what attributes and methods it had". So I did a obj.__dict__ and > found out that I could not. There must be some way to introspect the > object to get this info... just haven't figured out how yet. SQLObject adds these all to the class, so you should be able to look at obj.__class__.__dict__. Ian |