From diedrich at tux4web.de Fri Mar 12 15:27:34 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Fri Mar 12 15:10:20 2004 Subject: [orm-devel] The mailinglists are back! Message-ID: <16465.51414.85991.721230@lisa.local.> Hello everybody, after I have finally reclaimed my server with the orm mailinglist archives and the CVS repository(!) on it, I've been able to copy the lists to a new server and commit the (rather extensive) changes I made during the past view months. There's a new layout for the example and unit test direcory and view interface changes (most noteable the join class). I've started implementing some ideas for user interface programming with orm, which I've been using for a number of projects now, but I didn't clean up the code and write documentation and examples, yet. Check out the CVS version if you're interested! Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From eric at ericwalstad.com Fri Mar 12 16:33:19 2004 From: eric at ericwalstad.com (Eric Walstad) Date: Fri Mar 12 15:28:10 2004 Subject: [orm-devel] The mailinglists are back! In-Reply-To: <16465.51414.85991.721230@lisa.local.> References: <16465.51414.85991.721230@lisa.local.> Message-ID: <200403120733.19787.eric@ericwalstad.com> On Friday 12 March 2004 06:27, Diedrich Vorberg wrote: > Hello everybody, > > after I have finally reclaimed my server with the orm mailinglist > archives and the CVS repository(!) on it, I've been able to copy > the lists to a new server and commit the (rather extensive) changes > I made during the past view months. > > There's a new layout for the example and unit test direcory and > view interface changes (most noteable the join class). I've started > implementing some ideas for user interface programming with orm, > which I've been using for a number of projects now, but I didn't > clean up the code and write documentation and examples, yet. Check > out the CVS version if you're interested! > > Diedrich Hi Diedrich, Good to hear from you again. Congrats on the new server and the big commit. I'm looking forward to checking out your changes. Best regards, Eric. -- _________________________ Eric Walstad 740 Clementina Street San Francisco, CA 94103 415-864-4224 voice & fax http://ericwalstad.com/ _________________________ From diedrich at tux4web.de Mon Mar 15 11:41:13 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Mon Mar 15 11:43:44 2004 Subject: [orm-devel] New release: 0.13 Message-ID: <20040315104113.5086.qmail@mail2.tux4web.de> Hello everybody! I've just put a new orm release on the webserver. The release description reads: The delayed column type has been improved. This release also contains a better version of the user interface code including a simple example. There is no documentation on the user interface stuff, yet. The code may also be subject to rather massive changes, though I guess the basic ideas are going to stay. One more thing: Python 2.3 has introduced a new way of hooking into attribute setting and getting. This stuff looks like it was made just for orm! So be warned that orm might require Python 2.3 in the near future. Best wishes! Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From diedrich at tux4web.de Sun Mar 28 05:33:22 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Sun Mar 28 05:33:29 2004 Subject: [orm-devel] Non-alphanumeric column identifyers Message-ID: <16486.18306.785339.155556@bubbles.tux4web.de> Hello everybody! I've made changes to orm to allow the following to work: class email: columns = {'Subject': text(columnName='"Subject"'), 'MessageID': text(columnName='"Message-ID"') } as you see the MessageID attribute is mapped to a column whoes name is enclosed in "" in SQL. The " will be stripped of the identifyer in dbclass.py. (In MySQL you have to use ` instead of ", both possibilities are handled correctly). As a sidenote I'd like to welcome Charles Brandt on the list, who brought this up. Iresent his mail and my response to orm-users. Regards Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From lists at st.imul.us Mon Mar 29 00:38:55 2004 From: lists at st.imul.us (Charles Brandt) Date: Sun Mar 28 08:14:22 2004 Subject: [orm-devel] Re: ORM mailing list inquiry... References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> Message-ID: <005d01c41515$73fbb9f0$2a01a8c0@marge> Hi Diedrich, Thanks for the quick response! > I didn't know SQLObject was changed to use metaclasses. I didn't look > at their stuff for quite a while. I was going to change orm to use > metaclasses as well, but I'm not sure about it, yet. I must admit that I haven't had a chance to learn metaclasses yet. From what I've seen they look pretty slick, but they also seem to introduce a lot of complexity and maintenance overhead that I'm not sure is worth it. I think they introduce limitations on classes and objects as far as the namespace goes (required to be globally unique), and the whole initialization phase of an object became very tricky. This is probably what ultimately led to the finicky connection issues I experienced. It ideally wanted the connection to be specified in the class definition, vs passed in during object creation. Since I plan to reuse a connection within a thread, defining the connection at the class definition level is inconvenient. I'd be interested to hear your thoughts on the topic as you go down that path. Ian (the author of SQLObject) would also be a good one to talk to. I don't feel like I've done enough homework on the subject to discuss it intelligently. :) > I've change the server's harddisk and it seems like it didn't copy all > the files. I'll take a look at it later today. yay! its back! Have you considered subscribing the list to gmane.org? (http://gmane.org/subscribe.php) They make searching the archives fairly easy. ####################################### I came accross one extremely minor typo in dbclass.py, line 409: return "<" + self.__class__.__name__ + " (" + \ string.join(ret, " ") + ">" is missing a closing paren: return "<" + self.__class__.__name__ + " (" + \ string.join(ret, " ") + ")>" ####################################### I tried to check out the latest cvs source, but got the following response: cvs -d :pserver:anonymous@cvs.tux4web.de:/var/data/public_cvs login Logging in to :pserver:anonymous@cvs.tux4web.de:2401/var/data/public_cvs CVS password: cvs [login aborted]: unrecognized auth response from cvs.tux4web.de: Unknown command: `pserve' maybe a typo in the /etc/xinetd.d/pserver conf file? ####################################### One feature that I'm thinking about adding is a count method to the datasource.select. (inspired by SQLObject...) This would wrap the SQL COUNT(*) statement and might be handy when doing selects in batches. I was using this as a low cost test for the existence of a specific column value, but fetchall() should work fine in this case since there should only ever be zero or one value. ####################################### When testing if a fetchone() returned a value as follows: item = conn.select(MapItems, dkey-"sam").fetchone() if item: I get: File "/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site -packages/orm/dbclass.py", line 299, in __getattr__ if name[0] == "_": return self.__dict__[name] KeyError: '__nonzero__' It looks like __getattr__ is assuming that a attribute/column name is going to be sent along. Would it make sense to change name to a keyword argument with a default value set to return the dbclass (or a copy)? I suppose the easy answer to this is to just do a fetchall() and see if the resulting list has items. ####################################### > Documentation is behind... I know...:-( I'll try to help out if I can... need to look into editing docbook formats. I better go ahead and send this before it gets any longer. :) Thanks for the help Diedrich. -Charles. From diedrich at tux4web.de Sun Mar 28 11:34:11 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Sun Mar 28 11:34:29 2004 Subject: [orm-devel] Re: ORM mailing list inquiry... In-Reply-To: <005d01c41515$73fbb9f0$2a01a8c0@marge> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> <005d01c41515$73fbb9f0$2a01a8c0@marge> Message-ID: <16486.39955.120435.264889@bubbles.tux4web.de> Hi Charles! >I tried to check out the latest cvs source, but got the following response: >cvs -d :pserver:anonymous@cvs.tux4web.de:/var/data/public_cvs login >Logging in to :pserver:anonymous@cvs.tux4web.de:2401/var/data/public_cvs >CVS password: >cvs [login aborted]: unrecognized auth response from cvs.tux4web.de: Unknown >command: `pserve' > >maybe a typo in the /etc/xinetd.d/pserver conf file? It seems my inetd.conf got truncated. Please try again. >One feature that I'm thinking about adding is a count method to the >datasource.select. (inspired by SQLObject...) This would wrap the SQL >COUNT(*) statement and might be handy when doing selects in batches. I was >using this as a low cost test for the existence of a specific column value, >but fetchall() should work fine in this case since there should only ever be >zero or one value. Hm.. I'll think about a count() function. SelectResults do have a len(), see next question. >When testing if a fetchone() returned a value as follows: >item = conn.select(MapItems, dkey-"sam").fetchone() >if item: > >I get: > File >"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site >-packages/orm/dbclass.py", line 299, in __getattr__ > if name[0] == "_": return self.__dict__[name] >KeyError: '__nonzero__' I've added a dbclass.__nonzero__() function which is called by the "if". You might want to check then len of the result: result = conn.select(MapItems, dkey-"sam").fetchone() if len(result) == 0: # no result else: # result Also see the datasource.selectByPrimaryKey() function (which will raise an exception if there is no such object). >It looks like __getattr__ is assuming that a attribute/column name is going >to be sent along. Would it make sense to change name to a keyword argument >with a default value set to return the dbclass (or a copy)? That's not quite it: all method calles require attribute access to aquire the function pointer. This attribute access is intercepted by __getattr__() which is why the error occurs there. >####################################### >> Documentation is behind... I know...:-( >I'll try to help out if I can... need to look into editing docbook formats. I was going to switch to RestructuredText (see docutils.sf.net). If you like you can get cvs write access... >I better go ahead and send this before it gets any longer. :) Thanks for >the help Diedrich. No problem! Best wishes Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From lists at st.imul.us Tue Mar 30 04:41:19 2004 From: lists at st.imul.us (Charles Brandt) Date: Sun Mar 28 15:48:39 2004 Subject: [orm-devel] documentation: References: <014101c413e9$ceaf7710$2a01a8c0@marge><16484.34725.202034.843251@bubbles.tux4web.de><005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> Message-ID: <00b301c41600$7aefbf40$2a01a8c0@marge> Diedrich, CVS works like a champ now. Thanks! I started looking into the various utilities available to assist python documenation. Docutils definitely looks like a good choice for general documentation. I also came accross epydoc (http://epydoc.sourceforge.net) which yields instant gratification in the form of API docs. I'll send an attachment of the output generated (using latest CVS src) in a subsequent message to avoid binaries on the list. -Charles From diedrich at tux4web.de Sun Mar 28 18:09:50 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Sun Mar 28 18:10:11 2004 Subject: [orm-devel] documentation: In-Reply-To: <00b301c41600$7aefbf40$2a01a8c0@marge> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> <005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> <00b301c41600$7aefbf40$2a01a8c0@marge> Message-ID: <16486.63694.943435.790055@bubbles.tux4web.de> Hi Charles, >I started looking into the various utilities available to assist python >documenation. Docutils definitely looks like a good choice for general >documentation. I also came accross epydoc (http://epydoc.sourceforge.net) >which yields instant gratification in the form of API docs. I'll send an >attachment of the output generated (using latest CVS src) in a subsequent >message to avoid binaries on the list. this sure looks nice, kind of like JavaDoc output. Their docstring format is even close to (re) Structured Text. I think good API documentation is a must-have, but maybe even more important is good conceptual documentation. An FAQ would be nice and the introductory text orm.docbook needs an overhaul. As a first step I've taken an hour or so and added a number of docstrings for classes and methods I've added or modified during the past weeks. There is still much work to do here, but I think the comments in orm's are quite usefull compared to other projects. If you, Charles, have a couple of hours to spare I'd ask if you'd like to go over the comments, check them for comprehensibility, correct my poor spelling and while doing this start converting them to pydoc's format. This might even be a good way for you to learn about orm, so you'd be rewarded with personal benefit for your contribution ;-) Today I plan to look at the firebird adapter. I'll port the example programs to it and see how it works. Step three will be an overhaul of the non-docstring prose documentation. I plan to convert it to reStructuredText with some additions (syntax highlighting, CSS, etc). Also I'll add information on the things in orm that have changed since this document has been written. I'll probably put together an FAQ or a "cookbook", though I think adding extensive comments to the example application might do the job just as well as that even or better. People dealing with this *are* programmers and the examples seem like a very efficient way of conveying how orm works. Finally I'll start documenting the user interface stuff. I think it is very powerfull, but I don't think you can make head and foot of it without good documentation. Also this modules are far from being completed. I expect this to happen after the 1.0 release. This toppic being raised, I've decided to call the next stable orm release 1.0, bacause after that I'll change the infrastructure to use metaclasses. Also a lot of identifyers are going to change, too (practically all used by orm in dblcasses. I'll switch to Python's naming convention and use variable method names that look __like_this__ .) Wrapper classes for the old format will be provided and your current datamodels need not to be modified. Anyway, before 1.0 I'd like to make firebird work again and revamp the documentation. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From werner.bruhin at free.fr Tue Mar 30 14:19:07 2004 From: werner.bruhin at free.fr (Werner F. Bruhin) Date: Sun Mar 28 18:24:41 2004 Subject: [orm-devel] documentation: In-Reply-To: <16486.63694.943435.790055@bubbles.tux4web.de> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> <005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> <00b301c41600$7aefbf40$2a01a8c0@marge> <16486.63694.943435.790055@bubbles.tux4web.de> Message-ID: <406965BB.5030300@free.fr> Hi Diedrich, Great that you are going to update the Firebird adapter. I haven't had any time lately to look and/or work on ORM, should have at time to help at least on the testing side of things in a couple of weeks time, so let me know whenever testing will make sense. See you Werner Diedrich Vorberg wrote: >Hi Charles, > > > >>I started looking into the various utilities available to assist python >>documenation. Docutils definitely looks like a good choice for general >>documentation. I also came accross epydoc (http://epydoc.sourceforge.net) >>which yields instant gratification in the form of API docs. I'll send an >>attachment of the output generated (using latest CVS src) in a subsequent >>message to avoid binaries on the list. >> >> > >this sure looks nice, kind of like JavaDoc output. Their docstring >format is even close to (re) Structured Text. I think good API >documentation is a must-have, but maybe even more important is good >conceptual documentation. An FAQ would be nice and the introductory >text orm.docbook needs an overhaul. > >As a first step I've taken an hour or so and added a number of >docstrings for classes and methods I've added or modified during the >past weeks. There is still much work to do here, but I think the >comments in orm's are quite usefull compared to other projects. > >If you, Charles, have a couple of hours to spare I'd ask if you'd like >to go over the comments, check them for comprehensibility, correct my >poor spelling and while doing this start converting them to pydoc's >format. This might even be a good way for you to learn about orm, so >you'd be rewarded with personal benefit for your contribution ;-) > >Today I plan to look at the firebird adapter. I'll port the example >programs to it and see how it works. > >Step three will be an overhaul of the non-docstring prose >documentation. I plan to convert it to reStructuredText with some >additions (syntax highlighting, CSS, etc). Also I'll add information >on the things in orm that have changed since this document has been >written. I'll probably put together an FAQ or a "cookbook", though I >think adding extensive comments to the example application might do >the job just as well as that even or better. People dealing with this >*are* programmers and the examples seem like a very efficient way of >conveying how orm works. > >Finally I'll start documenting the user interface stuff. I think it is >very powerfull, but I don't think you can make head and foot of it >without good documentation. Also this modules are far from being >completed. I expect this to happen after the 1.0 release. > >This toppic being raised, I've decided to call the next stable orm >release 1.0, bacause after that I'll change the infrastructure to use >metaclasses. Also a lot of identifyers are going to change, too >(practically all used by orm in dblcasses. I'll switch to Python's >naming convention and use variable method names that look >__like_this__ .) Wrapper classes for the old format will be provided >and your current datamodels need not to be modified. Anyway, before >1.0 I'd like to make firebird work again and revamp the >documentation. > >Diedrich > > > From eric at ericwalstad.com Tue Mar 30 20:24:12 2004 From: eric at ericwalstad.com (Eric Walstad) Date: Sun Mar 28 20:03:19 2004 Subject: [orm-devel] documentation: In-Reply-To: <16486.63694.943435.790055@bubbles.tux4web.de> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <00b301c41600$7aefbf40$2a01a8c0@marge> <16486.63694.943435.790055@bubbles.tux4web.de> Message-ID: <200403301024.12863.eric@ericwalstad.com> Hi Diedrich, I wish I had some spare time to contribute to the documentation mods, but unfortunately, I've alloted my OS time to PebbleCDMaker (at sourceforge). I just want to mention that I think improving the documentation is a really good idea. Good documentation will make it easier for new users to come on board the ORM bandwagon, will likely make it more popular and therefore increase the number of eyes and brains reviewing and improving the code. I use ORM in an accounting app I wrote for my own use. ORM has served me well and I think others will benefit from it, especially if the documentation makes getting started with ORM even easier. Best regards, Eric. -- _________________________ Eric Walstad 740 Clementina Street San Francisco, CA 94103 415-864-4224 voice & fax eric@ericwalstad.com _________________________ From lists at st.imul.us Wed Mar 31 03:50:26 2004 From: lists at st.imul.us (Charles Brandt) Date: Sun Mar 28 22:03:49 2004 Subject: [orm-devel] post 1.0 and metaclasses References: <014101c413e9$ceaf7710$2a01a8c0@marge><16484.34725.202034.843251@bubbles.tux4web.de><005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> Message-ID: <012901c416c2$89eeeda0$2a01a8c0@marge> > This toppic being raised, I've decided to call the next stable orm > release 1.0, bacause after that I'll change the infrastructure to use > metaclasses. Also a lot of identifyers are going to change, too > (practically all used by orm in dblcasses. I'll switch to Python's > naming convention and use variable method names that look > __like_this__ .) Wrapper classes for the old format will be provided > and your current datamodels need not to be modified. I'm curious to hear what benefit you see in metaclasses vs the current approach. It seems to me the added complexity detracts from the idea of a thin membrane. It also raises the barrier of entry for others to contribute to the code. (or just follow along) When you add this with some of the limitations that (i think) are imposed by metaclasses (i.e. globally unique class names) I'm not sure if there is a compelling case. To me, this was one of the main distinguishing *features* of Object Membrane from SQLObject. Maybe features like automatic schema generation, or schema to class translators would attract more users instead? I'm interested to hear more thoughts on the topic if anyone has them. -charles. relevant links: http://mail.python.org/pipermail/python-list/2003-May/161119.html http://www-106.ibm.com/developerworks/linux/library/l-pymeta.html From lists at st.imul.us Wed Mar 31 04:05:57 2004 From: lists at st.imul.us (Charles Brandt) Date: Sun Mar 28 22:07:58 2004 Subject: [orm-devel] documentation: References: <014101c413e9$ceaf7710$2a01a8c0@marge><00b301c41600$7aefbf40$2a01a8c0@marge><16486.63694.943435.790055@bubbles.tux4web.de> <200403301024.12863.eric@ericwalstad.com> Message-ID: <012c01c416c4$b4cc3760$2a01a8c0@marge> > Good documentation will make it > easier for new users to come on board the ORM bandwagon, will likely > make it more popular and therefore increase the number of eyes and > brains reviewing and improving the code. Continuing along this line of thought, I was curious what people would think about a shift away from using ORM in the context of a name to something more unique like Object Membrane. I ask because "ORM" is often used in general discussions to refer to the broader concept of Object Relational Mapping, and someone looking for a specific ORM implementation might over look Object Membrane assuming it is a reference to the broader topic. This shift might also allow Google to index various resources more appropriately. I don't mind either way, and I know the abbreviation is easier to type... Maybe this is a non-issue. -Charles From lists at st.imul.us Wed Mar 31 04:19:15 2004 From: lists at st.imul.us (Charles Brandt) Date: Sun Mar 28 22:11:34 2004 Subject: [orm-devel] count vs len() References: <014101c413e9$ceaf7710$2a01a8c0@marge><16484.34725.202034.843251@bubbles.tux4web.de><005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> Message-ID: <012f01c416c6$90757910$2a01a8c0@marge> (sorry for all of the email... I thought it might be nice to separate these topics out by thread). > >One feature that I'm thinking about adding is a count method to the > >datasource.select. (inspired by SQLObject...) This would wrap the SQL > >COUNT(*) statement and might be handy when doing selects in batches. I was > >using this as a low cost test for the existence of a specific column value, > >but fetchall() should work fine in this case since there should only ever be > >zero or one value. > Hm.. I'll think about a count() function. > SelectResults do have a len(), see next question. I was thinking that on large tables fetchall could be inefficient if the length is the only data point required. I recently noticed the DelayedResult and was thinking maybe this could yield similar results without a potentially expensive select statement. I'll investigate further. For now I'm just using the execute for the custom statement (brittle, yes :) ): cursor = conn.execute("SELECT COUNT(*) FROM map_items") return cursor.rowcount -Charles From lists at st.imul.us Wed Mar 31 11:36:39 2004 From: lists at st.imul.us (Charles Brandt) Date: Wed Mar 31 11:11:29 2004 Subject: [orm-devel] default column value References: <014101c413e9$ceaf7710$2a01a8c0@marge><16484.34725.202034.843251@bubbles.tux4web.de><005d01c41515$73fbb9f0$2a01a8c0@marge><16486.39955.120435.264889@bubbles.tux4web.de> <012f01c416c6$90757910$2a01a8c0@marge> Message-ID: <014301c41703$abfd9540$2a01a8c0@marge> Hi List, I was wondering if there was a way to set a default value for a column. I checked in th column class and didn't see any mention of it, but I wanted to make sure I wasn't missing something. Would be handy for things like creation times in datetime columns. Maybe I'll look into adding that after some of these documention updates. Thanks! -Charles. From diedrich at tux4web.de Wed Mar 31 11:16:13 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Wed Mar 31 11:16:31 2004 Subject: [orm-devel] default column value In-Reply-To: <014301c41703$abfd9540$2a01a8c0@marge> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> <005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> <012f01c416c6$90757910$2a01a8c0@marge> <014301c41703$abfd9540$2a01a8c0@marge> Message-ID: <16490.35933.271978.830678@bubbles.tux4web.de> Hi Charles, >I was wondering if there was a way to set a default value for a column. I >checked in th column class and didn't see any mention of it, but I wanted to >make sure I wasn't missing something. Would be handy for things like >creation times in datetime columns. Maybe I'll look into adding that after >some of these documention updates. Thanks! just use your backend's DEFAULT functionality. If you do not set a dbobject's attribute explicitly the corresponding column will not be mentioned in the INSERT statement generated by orm. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From diedrich at tux4web.de Wed Mar 31 11:22:19 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Wed Mar 31 11:22:37 2004 Subject: [orm-devel] post 1.0 and metaclasses In-Reply-To: <012901c416c2$89eeeda0$2a01a8c0@marge> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> <005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> <012901c416c2$89eeeda0$2a01a8c0@marge> Message-ID: <16490.36299.207254.985487@bubbles.tux4web.de> Hi Charles, >I'm curious to hear what benefit you see in metaclasses vs the current >approach. The most obvious benefit would be inheritance: your dbclasses could subclass each other just like your tables in pgsql. >It seems to me the added complexity detracts from the idea of a >thin membrane. Actually, orm's four-thousand lines are mind-boggllingly complicated anyway ;-) The point is, orm's "datatypes" happen to mirror Python's property classes. If I would have had the understanding of Python that I have now I would have implemented orm with metaclasses. Using metaclasses I can make datatype inherit from property. This will make orm *much* more "pythonesque" i.e. closer to the intentions and style of language and runtime-system. >It also raises the barrier of entry for others to contribute >to the code. I can see that to understand metaclasses is difficult. To be honest, I only understood them day before yesturday and I guess, without working on orm I would not have understood them at all. But: In a way orm uses a lot of tricks to "emulate" metaclasses and properties. Using the actual technique provided by the language will make orm easier to understand and maintain. >When you add this with some of the limitations that (i think) are >imposed by metaclasses (i.e. globally unique class names) I'm not >sure if there is a compelling case. To me, this was one of the main >distinguishing *features* of Object Membrane from SQLObject. I'm not sure if globally unique class names is a limitation of metaclasses or a limitation of SQLObject. I will have to investigate... >Maybe features like automatic schema generation, or schema to class >translators would attract more users instead? I'm interested to hear >more thoughts on the topic if anyone has them. Me too... >http://mail.python.org/pipermail/python-list/2003-May/161119.html Ah... this is my first look at SQLObject for a long time... the syntax I have in mind for orm is much the same as SQLObject's. I guess I'll need to have a deeper look at it. Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From diedrich at tux4web.de Wed Mar 31 11:23:14 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Wed Mar 31 11:23:32 2004 Subject: [orm-devel] documentation: In-Reply-To: <012c01c416c4$b4cc3760$2a01a8c0@marge> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <00b301c41600$7aefbf40$2a01a8c0@marge> <16486.63694.943435.790055@bubbles.tux4web.de> <200403301024.12863.eric@ericwalstad.com> <012c01c416c4$b4cc3760$2a01a8c0@marge> Message-ID: <16490.36354.870313.432339@bubbles.tux4web.de> >Continuing along this line of thought, I was curious what people would think >about a shift away from using ORM in the context of a name to something more >unique like Object Membrane. I ask because "ORM" is often used in general >discussions to refer to the broader concept of Object Relational Mapping, >and someone looking for a specific ORM implementation might over look Object >Membrane assuming it is a reference to the broader topic. This shift might >also allow Google to index various resources more appropriately. I don't >mind either way, and I know the abbreviation is easier to type... Maybe >this is a non-issue. At the time I made it up, the name "orm" seemed like a great idea to me. Partly due to incompetance: I was not familiar with the abriviation "orm" for "Object Relational Mapper" ;-) I'm not sure if renaming would make that much sense: it does cause some confusion and maybe it's silly but on the other hand I get 30 hits or so per month from people googling for "python orm" :-) Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-" From diedrich at tux4web.de Wed Mar 31 11:24:47 2004 From: diedrich at tux4web.de (Diedrich Vorberg) Date: Wed Mar 31 11:25:06 2004 Subject: [orm-devel] count vs len() In-Reply-To: <012f01c416c6$90757910$2a01a8c0@marge> References: <014101c413e9$ceaf7710$2a01a8c0@marge> <16484.34725.202034.843251@bubbles.tux4web.de> <005d01c41515$73fbb9f0$2a01a8c0@marge> <16486.39955.120435.264889@bubbles.tux4web.de> <012f01c416c6$90757910$2a01a8c0@marge> Message-ID: <16490.36447.896290.877111@bubbles.tux4web.de> >> SelectResults do have a len(), see next question. > >I was thinking that on large tables fetchall could be inefficient if the >length is the only data point required. I recently noticed the >DelayedResult and was thinking maybe this could yield similar results >without a potentially expensive select statement. I'll investigate further. >For now I'm just using the execute for the custom statement (brittle, yes >:) ): > > cursor = conn.execute("SELECT COUNT(*) FROM map_items") > return cursor.rowcount See datasource.py:711: queryResult::__len__() It does the same thing! The comment on the function is no longer accurate: psycopg _does_ provide rowcount! result = ds.select(model.map_item) return len(result) Diedrich -- Diedrich Vorberg .---. / \ http://tux4web.de Tel: 02302 425269 / \ ((__-^^-,-^^-__)) \.O-O./ `-_---' `---_-' "Unix is simple, but it takes a genius /`\_/`\ `--|o` 'o|--' to understand the simplicity." // _ \\ \ ` / - Dennis Ritchie | \ )|_ ): :( /`\_`> <_/ \ :o_o: Associate Member of the FSF #1245 \__/'---'\__/ "-"