Thread: [SQLObject] Adding comment to a column
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Randall S. <ra...@tn...> - 2005-10-27 20:35:44
|
I'v enjoyed generating tables from my classes more than I thought I would. One thing I would like to have though is comments for the columns. Is there a way to do this so when my tables are automatically generated, column comments are included in the databases's column definition? Would be nice if it would read a doc string. Randall |
From: Rick F. <rf...@im...> - 2005-10-27 20:40:35
|
You could do this with createSQL, but your comments wouldn't be acessible in SQLObject unless you made your own methods for them. What do you propose a doc string would look like? I've been thinking about this addition too, but I haven't thought about how it should work. -- Rick On Thu, 27 Oct 2005, Randall Smith wrote: > I'v enjoyed generating tables from my classes more than I thought I would. > One thing I would like to have though is comments for the columns. Is there > a way to do this so when my tables are automatically generated, column > comments are included in the databases's column definition? Would be nice if > it would read a doc string. > > Randall > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Ian B. <ia...@co...> - 2005-10-27 21:10:57
|
Rick Flosi wrote: > You could do this with createSQL, but your comments wouldn't be > acessible in SQLObject unless you made your own methods for them. > > What do you propose a doc string would look like? I've been thinking about changing column descriptors to be classes. So instead of, say, StringCol and SOStringCol, each column in a class would be a StringCol subclass, and the object tied to the specific class (and not shared with subclasses) would be an instance of that object. So these would be mostly equivalent: class Foo(SQLObject): class name(StringCol): length=100 class Foo2(SQLObject): name = StringCol(length=100) Then the natural comment would be __doc__, either as a docstring or as a __doc__ keyword argument. Maybe with an optional comment field, since __doc__ is awkward, and comment would allow you a Python docstring and a database comment at the same time. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Jorge G. <go...@ie...> - 2005-10-27 21:25:40
|
Ian Bicking <ia...@co...> writes: > I've been thinking about changing column descriptors to be classes. So > instead of, say, StringCol and SOStringCol, each column in a class would > be a StringCol subclass, and the object tied to the specific class (and > not shared with subclasses) would be an instance of that object. So > these would be mostly equivalent: > > class Foo(SQLObject): > class name(StringCol): > length=100 > > class Foo2(SQLObject): > name = StringCol(length=100) > > Then the natural comment would be __doc__, either as a docstring or as a > __doc__ keyword argument. Maybe with an optional comment field, since > __doc__ is awkward, and comment would allow you a Python docstring and a > database comment at the same time. Hmmmm... How would we keep the behaviour of getters, setters, inheritance, etc.? What would be the benefit, besides the ability to use docstrings for each column? And if there's a 'comment' keyword, why should one use a docstring? I'm a lot into using doxygen for documentation of my Python code, so I might be biased on not caring too much about docstrings... -- Jorge Godoy <go...@ie...> |
From: Ian B. <ia...@co...> - 2005-10-27 21:44:34
|
Jorge Godoy wrote: > Ian Bicking <ia...@co...> writes: > > >>I've been thinking about changing column descriptors to be classes. So >>instead of, say, StringCol and SOStringCol, each column in a class would >>be a StringCol subclass, and the object tied to the specific class (and >>not shared with subclasses) would be an instance of that object. So >>these would be mostly equivalent: >> >>class Foo(SQLObject): >> class name(StringCol): >> length=100 >> >>class Foo2(SQLObject): >> name = StringCol(length=100) >> >>Then the natural comment would be __doc__, either as a docstring or as a >>__doc__ keyword argument. Maybe with an optional comment field, since >>__doc__ is awkward, and comment would allow you a Python docstring and a >>database comment at the same time. > > > Hmmmm... How would we keep the behaviour of getters, setters, inheritance, > etc.? What would be the benefit, besides the ability to use docstrings for > each column? And if there's a 'comment' keyword, why should one use a > docstring? If there was a docstring and comment keyword, the comment would apply to the database, and the docstring to the Python side. In terms of getters and setters, the instances would be descriptors, i.e., StringCol.__get__ and __set__, instead of properties. They could even have __sqlrepr__ methods (or the new __sqlwhateveritis__ for db parameters), thus Foo.q.column wouldn't be necessary anymore -- Foo.column would be sufficient (Foo.q.column would still be around of course, backward compatibility and all). And there'd be a new style for overrides, like: class Foo(SQLObject): class name(StringCol): def set(self, value, setter): setter(value.lower()) Which would be functionally equivalent to: class Foo(SQLObject): name = StringCol() def _set_name(self, value): self._SO_set_name(value.lower()) -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Jorge G. <go...@ie...> - 2005-10-27 20:54:05
|
Rick Flosi <rf...@im...> writes: > You could do this with createSQL, but your comments wouldn't be acessible > in SQLObject unless you made your own methods for them. > > What do you propose a doc string would look like? > > I've been thinking about this addition too, but I haven't thought about > how it should work. I think it should be a 'doc' or 'comment' attribute passed to the *Col method. -- Jorge Godoy <go...@ie...> |
From: Jorge G. <go...@ie...> - 2005-10-27 22:16:48
|
Ian Bicking <ia...@co...> writes: > In terms of getters and setters, the instances would be descriptors, > i.e., StringCol.__get__ and __set__, instead of properties. They could > even have __sqlrepr__ methods (or the new __sqlwhateveritis__ for db > parameters), thus Foo.q.column wouldn't be necessary anymore -- > Foo.column would be sufficient (Foo.q.column would still be around of > course, backward compatibility and all). And there'd be a new style for > overrides, like: Sounds interesting. And looks cleaner... I'm not all that into nested classes, but it looks cleaner here. Adding stuff should be easier too... It is just writing a new subclass or method... Eliminating que 'q' would be very good and make things more 'natural'... Be seeing you, -- Jorge Godoy <go...@ie...> |