From orm-devel@mailman.tux4web.de Sun Dec 1 12:04:34 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sun, 1 Dec 2002 13:04:34 +0100 Subject: [orm-devel] Unified Connection Strings Message-ID: <15849.64210.947371.650968@lisa.tux4web.de> A good day to everyone :-) I'll have to make a design decision regarding orm and I'd like to hear your opinions on this: Writing the test programs I would have liked to add the ablility to pass connections parameters as a single string on the command line. Here I used -u -d -p parameters to get around this. Now I'm writing a ORMDatasourcePool Product for Zope and ran into the same problem: how to specify database connection parameters in a unified way. There are two approaches I'm considering (any more ideas very welcome): PostgreSQL's DSN syntax: dsn = "adapter=pgsql dbname=test user=diedrich password=secret" or the JDBC style urls url = "pgsql://diedrich:secret@localhost/test" Personally I like Postgres' way of doing things better: easier to read, easier to parse and all in all very practical. The url style's advantages are: they are used by one of the most popular database access infrastructure and they fit into a single string on the command line. Does anyone know who else is using this url style notation? Is there a standard like an RFC or so? Do you think it's worth the effort to support both? Any comment is very welcome! Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sun Dec 1 16:02:43 2002 From: orm-devel@mailman.tux4web.de (Mike Watkins) Date: Sun, 01 Dec 2002 08:02:43 -0800 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <15849.64210.947371.650968@lisa.tux4web.de> Message-ID: <5.1.0.14.0.20021201075258.02a90a58@mail.mikewatkins.net> My vote is for the 'Postgres' style dsn = "adapter=pgsql dbname=test user=diedrich password=secret" Another Python Postgres DA uses the format: connect_string = 'host:port:database:user:password:options:tty' But I'm in favor of clarity, so the latter example fails because when optional parameters are missing you end up with something like: connect_string = 'orpheum::testdb::::' which isn't very clear to me. arg = parameter I can remember ! Plus it is easily extended with new args should the need arise. At 01:04 PM 12/1/2002 +0100, you wrote: >A good day to everyone :-) > >I'll have to make a design decision regarding orm and I'd like to >hear your opinions on this: > >Writing the test programs I would have liked to add the ablility to >pass connections parameters as a single string on the command line. >Here I used -u -d -p parameters to get around this. Now I'm writing a >ORMDatasourcePool Product for Zope and ran into the same problem: how >to specify database connection parameters in a unified way. > >There are two approaches I'm considering (any more ideas very >welcome): PostgreSQL's DSN syntax: > > dsn = "adapter=pgsql dbname=test user=diedrich password=secret" > >or the JDBC style urls > > url = "pgsql://diedrich:secret@localhost/test" > >Personally I like Postgres' way of doing things better: easier to >read, easier to parse and all in all very practical. The url style's >advantages are: they are used by one of the most popular database >access infrastructure and they fit into a single string on the command >line. > >Does anyone know who else is using this url style notation? Is there >a standard like an RFC or so? Do you think it's worth the effort to >support both? > >Any comment is very welcome! > >Diedrich > >-- > _..._ Diedrich Vorberg > .' '. > / _ _ \ http://www.tux4web.de > | (o)_(o) | info@tux4web.de > \( ) / .---. > //'._.'\ \ / \ Internet Dienstleistungen > // . \ \ \.@-@./ und 'Consulting'. > || . \ \ /`\_/`\ > |\ : / | // _ \\ Linux Rules! > \ `) ' (` /_ | \ )|_ > _)``".____,.'"` (_ /`\_`> <_/ \ > ) )'--'( ( \__/'---'\__/ > '---` `---` > >_______________________________________________ >orm-devel mailing list >orm-devel@mailman.tux4web.de >http://mailman.tux4web.de/mailman/listinfo/orm-devel From orm-devel@mailman.tux4web.de Mon Dec 2 04:09:35 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Sun, 1 Dec 2002 22:09:35 -0600 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <15849.64210.947371.650968@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> Message-ID: <20021202040934.GA13752@wallace.ece.rice.edu> On Sun, Dec 01, 2002 at 01:04:34PM +0100, Diedrich Vorberg wrote: > I'll have to make a design decision regarding orm and I'd like to > hear your opinions on this: > > Writing the test programs I would have liked to add the ablility to > pass connections parameters as a single string on the command line. > Here I used -u -d -p parameters to get around this. Now I'm writing a > ORMDatasourcePool Product for Zope and ran into the same problem: how > to specify database connection parameters in a unified way. Hmm, what is a ORMDatasourcePool Product? I was just looking at what it would take use orm from inside other Zope products, using a Zope SQL DA as the datasource. Is that anything like what you're up to, or something even more integrated? > There are two approaches I'm considering (any more ideas very > welcome): PostgreSQL's DSN syntax: > > dsn = "adapter=pgsql dbname=test user=diedrich password=secret" > > or the JDBC style urls > > url = "pgsql://diedrich:secret@localhost/test" I'm partial to the first: it seems more pythonic, as well. Ross From orm-devel@mailman.tux4web.de Mon Dec 2 09:50:11 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 2 Dec 2002 10:50:11 +0100 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <20021202040934.GA13752@wallace.ece.rice.edu> References: <15849.64210.947371.650968@lisa.tux4web.de> <20021202040934.GA13752@wallace.ece.rice.edu> Message-ID: <15851.11475.168927.275032@lisa.tux4web.de> Hi Ross, >Hmm, what is a ORMDatasourcePool Product? I was just looking at what it >would take use orm from inside other Zope products, using a Zope SQL DA >as the datasource. Is that anything like what you're up to, or something >even more integrated? This is my solution using a Zope SQL DA (ZPsycopgDA), just subclassing the PostgreSQL datasource. class datasource(orm.adapters.psql.datasource.datasource): """ We're using Zope's mechanism for database connections here. This is a subclass of orm's psycopg adapter. """ def __init__(self, context): zope_ds = context.restrictedTraverse("zope_ds") self._conn = zope_ds().db self._encoding = "iso-8859-1" self._dsn = "" The problem I can see is, that there is only one connection to the database. PostgreSQL will maintain transactions connection-wise. So if one of my threads runs a couple of queries on one connection and another runs a rollback() on that connection my changes are lost. Even an unwanted commit() might lead to trouble. The Zope Product I'm currently working on is in the CVS contrib directory, but be warned it, is rather primitive :-) It provides (besides the Zope Management facilities) two methods: aquire() and release(). There is a minium and maximum number of connections the Pool will create to the RDBMS. aquire() will return one to you if one is available or open a new one for you. If the maximum number of open connections is reached it will make you wait until one is released(). This is untested, I'm going to start working with it today. There is a rather nasty problem with ORM and Zope. ORM requires Python 2.2, because of Python's builtin classmethod(). Zope will warn about 2.1 being the preferred version to run it with, but to my experience will run fine. The problem: starting Zope using Python 2.2 takes forever, which is a pain when developing a product. My solution (er... workaround) is to have two version of my Application, one that runs on 2.2 and one that runs on 2.1 using a defunc version of ORM. You can use 2.2 and Zope just make sure you have some kind of way to reload() all your modules without restarting Zope. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Mon Dec 2 16:56:01 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Mon, 2 Dec 2002 10:56:01 -0600 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <15851.11475.168927.275032@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> <20021202040934.GA13752@wallace.ece.rice.edu> <15851.11475.168927.275032@lisa.tux4web.de> Message-ID: <20021202165601.GA18537@wallace.ece.rice.edu> On Mon, Dec 02, 2002 at 10:50:11AM +0100, Diedrich Vorberg wrote: > Hi Ross, > > This is my solution using a Zope SQL DA (ZPsycopgDA), just > subclassing the PostgreSQL datasource. > > class datasource(orm.adapters.psql.datasource.datasource): > """ > We're using Zope's mechanism for database connections here. > This is a subclass of orm's psycopg adapter. > """ > > def __init__(self, context): > zope_ds = context.restrictedTraverse("zope_ds") > self._conn = zope_ds().db > self._encoding = "iso-8859-1" > self._dsn = "" Ah, this looks useful. > The problem I can see is, that there is only one connection to the > database. PostgreSQL will maintain transactions connection-wise. So > if one of my threads runs a couple of queries on one connection and > another runs a rollback() on that connection my changes are lost. > Even an unwanted commit() might lead to trouble. Yup, you've _got_ to use the connection pool. > The Zope Product I'm currently working on is in the CVS contrib > directory, but be warned it, is rather primitive :-) It provides > (besides the Zope Management facilities) two methods: aquire() and > release(). There is a minium and maximum number of connections the > Pool will create to the RDBMS. aquire() will return one to you if > one is available or open a new one for you. If the maximum number of > open connections is reached it will make you wait until one is > released(). > > This is untested, I'm going to start working with it today. Hmm, so this means your build a connection pool on top of the existing Zope connection pool? I thought the Zope pool was careful about not letting multiple Zope threads use the same connection. If you've seen otherwise, however ... Or is your orm-using app also using threads itself? orm doesn't multithread on it's own, right? > There is a rather nasty problem with ORM and Zope. ORM requires > Python 2.2, because of Python's builtin classmethod(). Zope will warn > about 2.1 being the preferred version to run it with, but to my Right, I already ran into this. So, I've seen a number of partial implementations of classmethod() for use on 2.1: there's one on ASPN, one in the cookbook, and one I just saw on python-list in June. How unlikely would it be to get orm-cvs to work under 2.1? Hmm, I see the next hurdle is subclassing from the 'list' builtin. Ross From orm-devel@mailman.tux4web.de Mon Dec 2 22:25:28 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Mon, 2 Dec 2002 23:25:28 +0100 Subject: [orm-devel] ORM and Zope (was: Unified Connection Strings) In-Reply-To: <20021202165601.GA18537@wallace.ece.rice.edu> References: <15849.64210.947371.650968@lisa.tux4web.de> <20021202040934.GA13752@wallace.ece.rice.edu> <15851.11475.168927.275032@lisa.tux4web.de> <20021202165601.GA18537@wallace.ece.rice.edu> Message-ID: <15851.56792.4039.499693@lisa.tux4web.de> Hi Ross, >Hmm, so this means your build a connection pool on top of the existing >Zope connection pool? I thought the Zope pool was careful about not >letting multiple Zope threads use the same connection. If you've seen I does?! (Yes it does I checked the docs.) Man... I should have read more documentation. I seem to keep underestemating Zope :-) There are two things my little pool product does: it has an upper limit of open connections to the RDBMS and when ready it will work with any backend supported by ORM. Otherwise it's pretty useless, I guess :-( >orm doesn't multithread on it's own, right? Right, it isn't. >> There is a rather nasty problem with ORM and Zope. ORM requires >> Python 2.2, because of Python's builtin classmethod(). Zope will warn >> about 2.1 being the preferred version to run it with, but to my > >Right, I already ran into this. So, I've seen a number of partial >implementations of classmethod() for use on 2.1: there's one on ASPN, >one in the cookbook, and one I just saw on python-list in June. How >unlikely would it be to get orm-cvs to work under 2.1? Hmm, I see the >next hurdle is subclassing from the 'list' builtin. The classmethod() workarounds I found didn't seem to work. We could replace list with UserList, but the problem I see is that we would not only have to test each modification against a number of different backends but also against two versions of Python. I wonder if it's worth the trouble. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Tue Dec 3 09:33:31 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Tue, 3 Dec 2002 10:33:31 +0100 Subject: [orm-devel] Re: Unified Connection Strings In-Reply-To: <15849.64210.947371.650968@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> Message-ID: <15852.31339.79318.994811@lisa.tux4web.de> Hallo, there is a version with a unified format for connection strings in the CVS repository. the orm.datasource.datasource docstring: """ Return a ORM datasource object constructed from a connection string. The connection strings follow the conventions for PostgreSQL DSNs: they consist of keyword=value pairs seperated with whitespace. Keywords recognized are: adapter - name of the ORM adapter used. Use the name from the adapters/ directory. db - name of the database to connect to user - Database username password - Password used for authentication host - hostname or IP address of the machine the database runs on (note that there might be a difference if you use 127.0.0.1 or localhost. The first creating a tcp/ip connection, the latter a unix/fifo connection. This is true for at leas psql and mysql Each of the database backends may define its own keywords. For instance PostgreSQL will understand each of the original keywords as aliases. Check the documentation! Values may not contain spaces. """ Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Tue Dec 3 16:06:42 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Tue, 3 Dec 2002 10:06:42 -0600 Subject: [orm-devel] Re: Unified Connection Strings In-Reply-To: <15852.31339.79318.994811@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> <15852.31339.79318.994811@lisa.tux4web.de> Message-ID: <20021203160642.GB29455@wallace.ece.rice.edu> On Tue, Dec 03, 2002 at 10:33:31AM +0100, Diedrich Vorberg wrote: > Hallo, > > there is a version with a unified format for connection strings in the > CVS repository. > > the orm.datasource.datasource docstring: > > """ > Return a ORM datasource object constructed from a connection string. > > The connection strings follow the conventions for PostgreSQL DSNs: > they consist of keyword=value pairs seperated with whitespace. > Keywords recognized are: > > adapter - name of the ORM adapter used. Use the name from the > adapters/ directory. Yeah, about that: the PostgreSQL adapter is currently named 'psql'. That's unfortunate, since the usual shorthand is 'pgsql', with 'psql' resevered for the commandline interface tool. How do people feel about changing it? renaming directories in CVS is a right pain, I know, but the confusion factor is definitely there. Ross From orm-devel@mailman.tux4web.de Tue Dec 3 16:20:18 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Tue, 3 Dec 2002 17:20:18 +0100 Subject: [orm-devel] Re: Unified Connection Strings In-Reply-To: <20021203160642.GB29455@wallace.ece.rice.edu> References: <15849.64210.947371.650968@lisa.tux4web.de> <15852.31339.79318.994811@lisa.tux4web.de> <20021203160642.GB29455@wallace.ece.rice.edu> Message-ID: <15852.55746.731331.598281@lisa.tux4web.de> Hi Ross, >Yeah, about that: the PostgreSQL adapter is currently named 'psql'. That's >unfortunate, since the usual shorthand is 'pgsql', with 'psql' resevered >for the commandline interface tool. How do people feel about changing it? >renaming directories in CVS is a right pain, I know, but the confusion >factor is definitely there. d*mn... I was hoping nobody would see this ;-) Yes, I'm positiv about renaming. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Thu Dec 5 00:31:41 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: 05 Dec 2002 01:31:41 +0100 Subject: [orm-devel] Renaming psql to pgsql Message-ID: <87bs41s3v6.fsf@lisa.tux4web.de> Hallo, I've renamed the adapters/psql direcory to adapters/pgsql **in the repositody**. This will make in necessary for you to re-checkout orm completely. cvs update will work, but give you a warning. Checking in changes in the psql directory will not work! Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Thu Dec 5 05:14:41 2002 From: orm-devel@mailman.tux4web.de (Julio Rommi =?iso-8859-1?q?O=F1a=20Miranda?=) Date: Thu, 5 Dec 2002 01:14:41 -0400 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <15849.64210.947371.650968@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> Message-ID: <20021205051639.06854763B@pinky.miranda> Hi everyone, El Dom 01 Dic 2002 08:04, escribió: > > Does anyone know who else is using this url style notation? Is there > a standard like an RFC or so? Do you think it's worth the effort to > support both? > > Any comment is very welcome! > > Diedrich I was reviewing some documentation this time (DivePython indeed), and I've saw how to concatenate strings and use optional arguments... so I recall how datasource is called when a selections is maded. If you look there could be use the same way to open a connection: ds= datasource(driver="pgsql", user="me", password="thispassword",dbname="test",host="myhost") and with this datasource shoud create the dns string needed to connect to the postgrest server: "user=me password=thispassword dbname=test host=myhost". In the same way if we say: ds1= datasource(driver="mysql", user="me", password="thispassword",dbname="test",host="myhost") the datasource clase shoud translate the parameters to user, passwd, db, host and create the requested structure to call the mysql server. Datasource shoud request the needed information to connect a database type and ignore the suplementary information that is no needed by others. Including driver as a parameter allows us to have more than a database source (and type). Of course, datasource class logic should take this on account and search the driver in the orm path, in other words when "mysql" is gived to it, then mysql modules (in the mysql dir) shoud be imported. This has an implication on column classes, so they shoud be generic respect the database so orm dbclass use the respective column/columndata classes depending the driver used. Ok, just a little idea, (you can flame me if you want ;-P Regards. -- Julio From orm-devel@mailman.tux4web.de Thu Dec 5 23:46:44 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Thu, 5 Dec 2002 15:46:44 -0800 (PST) Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release Message-ID: <20021205234644.7881.qmail@web11001.mail.yahoo.com> Hi All, First off, thanks for ORM! I had to develop something like it before from scratch (nothing as comprehensive as orm) so I can really appreciate the work you've already done! Also, I enjoy using it. I am putting myself through an exercise of learning both ORM and wxPython by converting my business administration database to wxPython and ORM. I started out with ORM 0.4.2. It was working well until I tried to commit some data of type "numeric." In 0.4.2 the numeric column and datatype classes were incomplete and I was receiving errors when I'd try to commit the data to postgres. So, I just downloaded the latest ORM (0.7) and have made the necessary changes to my import statements to accomodate the new package structure (MySQL support, YAY!). I ran into a couple more problems, so I subscribed to the mailing lists and found your cvs and downloaded it. I'm still having a bit of trouble with "numeric" data: psycopg.ProgrammingError: ERROR: parser: parse error at or near "=<" UPDATE projects SET job_number='2002-057', [snip other columns], bid_price=, city='San Francisco' WHERE id=315 As you can see, the "Bid Price" float is not getting converted correctly and therefore the SQL is invalid. I dug around a bit in orm/columns.py -> _numerical.convert() method, but didn't see anything there. Here's the SQL used to create the table: CREATE TABLE "projects" ( "id" integer DEFAULT nextval('"projects_id_seq"'::text) NOT NULL, "contacts_id" integer, "job_number" character varying(20), "project_date" timestamp without time zone DEFAULT now(), "name" character varying(50), "address" character varying(50), "city" character varying(50), "state" character(2) DEFAULT 'CA', "zip" character varying(50), "project_type" character varying(50), "bid_price" numeric(8,2), Constraint "projects_pkey" Primary Key ("id") ); And here's the corresponding dbclass constructor: class projects(dbclass): columns = { "id" :integer(), "contacts_id" :integer(), "job_number" :varchar(), "project_date" :timestamp(), "name" :varchar(), "address" :varchar(), "city" :varchar(), "state" :char(), "zip" :varchar(), "project_type" :varchar(), "bid_price" :float(), "invoices" :one2many(invoices, "project_id")} __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From orm-devel@mailman.tux4web.de Thu Dec 5 23:59:04 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Thu, 5 Dec 2002 15:59:04 -0800 (PST) Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release In-Reply-To: <20021205234644.7881.qmail@web11001.mail.yahoo.com> Message-ID: <20021205235904.92770.qmail@web11007.mail.yahoo.com> The tail of my message was cut off. I'll append it here... --- Eric Walstad wrote: > Hi All, [snip] > psycopg.ProgrammingError: ERROR: parser: parse error at or near "=<" > UPDATE projects SET job_number='2002-057', [snip other columns], > bid_price=, city='San > Francisco' > WHERE id=315 > > As you can see, the "Bid Price" float is not getting converted correctly > and therefore the SQL is invalid. I dug around a bit in orm/columns.py > -> > _numerical.convert() method, but didn't see anything there. > > Here's the SQL used to create the table: > CREATE TABLE "projects" ( > "id" integer DEFAULT nextval('"projects_id_seq"'::text) NOT NULL, > "contacts_id" integer, > "job_number" character varying(20), > "project_date" timestamp without time zone DEFAULT now(), > "name" character varying(50), > "address" character varying(50), > "city" character varying(50), > "state" character(2) DEFAULT 'CA', > "zip" character varying(50), > "project_type" character varying(50), > "bid_price" numeric(8,2), > Constraint "projects_pkey" Primary Key ("id") > ); > > And here's the corresponding dbclass constructor: > class projects(dbclass): > columns = { "id" :integer(), > "contacts_id" :integer(), > "job_number" :varchar(), > "project_date" :timestamp(), > "name" :varchar(), > "address" :varchar(), > "city" :varchar(), > "state" :char(), > "zip" :varchar(), > "project_type" :varchar(), > "bid_price" :float(), > "invoices" :one2many(invoices, "project_id")} I'd like to be able to do: "bid_price" :numeric(), but there is no numeric type around line 546 in orm/columns.py, which I'm guessing would look like: # float point quantities float, floatColumn = _float, _floatColumn numeric, numericColumn = _float, _floatColumn Any pointers would be appreciated. Best regards and thanks again, Eric Walstad, San Francisco __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From orm-devel@mailman.tux4web.de Fri Dec 6 09:44:52 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 6 Dec 2002 10:44:52 +0100 Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release In-Reply-To: <20021205235904.92770.qmail@web11007.mail.yahoo.com> References: <20021205234644.7881.qmail@web11001.mail.yahoo.com> <20021205235904.92770.qmail@web11007.mail.yahoo.com> Message-ID: <15856.29076.236315.68786@lisa.tux4web.de> Hi Eric, thank you very much for the nice words you found about ORM! Your encouragement is very much appreciated! >> psycopg.ProgrammingError: ERROR: parser: parse error at or near "=<" >> UPDATE projects SET job_number='2002-057', [snip other columns], >> bid_price=, city='San >> Francisco' >> WHERE id=315 I don't seem to be able to reproduce this. Could you take a look at the assignment of the new value? Do you assign a float number or a column instance? Perhaps just cut and paste the code ... >I'd like to be able to do: >"bid_price" :numeric(), >but there is no numeric type around line 546 in orm/columns.py, which I'm >guessing would look like: Yes, I know... ># float point quantities >float, floatColumn = _float, _floatColumn >numeric, numericColumn = _float, _floatColumn No, that's not the way I wanted to go. The PostgreSQL NUMBERIC type is for arbitrary precision quanteties, see, the the Python float type has 64 bit (I think). 64 bit's pretty large, but it's not arbitrary. I was going to use the egenix-experimental mx.Number class to represent arbitrary numerals in ORM. The problem is, it doesn't compile out-of-the-box on my maching (MacOSX). I'm going to look into this right away and if I get it to run I'll put the numerical type for PostgreSQL in the CVS. >Eric Walstad, >San Francisco San Francisco... whow... :-)) Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Dec 6 09:45:34 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 6 Dec 2002 10:45:34 +0100 Subject: [orm-devel] Re: ORM Message-ID: <15856.29118.239734.580936@lisa.tux4web.de> ------- start of forwarded message (RFC 934 encapsulation) ------- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-Path: Delivered-To: tux4web.de-diedrich@tux4web.de Received: (qmail 17363 invoked by uid 0); 5 Dec 2002 23:49:44 -0000 Received: from unknown (HELO power.connexus.net.au) (203.12.22.20) by ns.tux4web.de with SMTP; 5 Dec 2002 23:49:44 -0000 Received: from microshare.com.au (75-78.dsl.connexus.net.au [203.222.75.78]) by power.connexus.net.au (8.12.4/8.11.6) with SMTP id gB5Nkwl5052332 for ; Fri, 6 Dec 2002 10:46:59 +1100 (EST) (envelope-from uwe@microshare.com.au) XAntiVirus: This e-mail has been scanned for viruses via the Connexus Internet Service Received: (qmail 26977 invoked from network); 5 Dec 2002 23:47:56 -0000 Received: from pc-00010 (192.168.20.10) by envision.microshare.com.au (192.168.20.1) with ESMTP; 05 Dec 2002 23:47:56 -0000 Message-Id: <1039168144.10276.48.camel@eeyore> To: diedrich@tux4web.de From: "Uwe (Peter) Feldtmann" Date: 06 Dec 2002 09:49:04 +0000 Subject: ORM X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Hi Diedrich, I am building an Open Source Accounting package in Python using postgres, psycopg, wxPython etc and orm looks like it might be just what I needed as I'm new to all the above. My questions are Does orm handle table inheritance? What are the performance and memory penalties for using orm? Can orm be used to create the tables based on the column defs? Do all the table classes need to be imported at once or can we do "from beans import person, address"? Sorry if my questions appear silly. I'm new to Python and to SQL. I have been developing accounting systems for 22 years using 4GL's and this will be my last one so any assistance or advice would be greatly appreciated. Thanks in advance. Yours, Uwe Feldtmann. ------- end ------- -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Dec 6 10:09:08 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 6 Dec 2002 11:09:08 +0100 Subject: [orm-devel] Re: ORM In-Reply-To: <15856.29118.239734.580936@lisa.tux4web.de> References: <15856.29118.239734.580936@lisa.tux4web.de> Message-ID: <15856.30532.3302.286222@lisa.tux4web.de> Hi Uwe, for a moment I though you to be Austrian, with that German name and all. But after checking I figured you're not only across the Alps but even Down Under... >My questions are > Does orm handle table inheritance? Well... not really. What I usually do is this: class base(dbclass): columns = {"id": serial(), "name": varchar()} class child(base): columns = base.column.copy().update({ "surname": varchar(), "age": integer() }) This way the Python classes have a parent/child relationship as the tables do. Unfortunately you'll have to take care of the child having the right clumns by hand. Note that it is essential to use base.columns.copy(), because otherwise you'll modify base's column dics as well! > What are the performance and memory penalties for using orm? Minimal I'd suppose. See, ORM is rather simple in nature, (actually that's the point in it :-) and things you do to your dbObjects will translate to SQL commands directly. There is a certain overhead of function calls, of course. An asignment will call dbobj.__setattr__ (the column class') set() (the datasource's) update() (the datatype's) format() (with the commit() or flushUpdates()) datasource.execute() And some more I don't know by heart. But there are no expensive computations involved, really. > Can orm be used to create the tables based on the column defs? No. Mike Watkins sent a program in that goes the other way 'round and creates orm's class definitions from the SQL layout. Check the contrib/ directory. > Do all the table classes need to be imported at once or can > we do "from beans import person, address"? This import statement will work as expected. >Sorry if my questions appear silly. I'm new to Python and to SQL. I have >been developing accounting systems for 22 years using 4GL's and this >will be my last one so any assistance or advice would be greatly >appreciated. There's no such thing as a silly question, just silly answers. You have nearly as much programming experience as I am old ;-) If there is any advise or suggestions from your side, I'm eager to hear them! BTW: what are 4GL's? >Uwe Feldtmann. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Dec 6 10:55:29 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 6 Dec 2002 11:55:29 +0100 Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release In-Reply-To: <20021205235904.92770.qmail@web11007.mail.yahoo.com> References: <20021205234644.7881.qmail@web11001.mail.yahoo.com> <20021205235904.92770.qmail@web11007.mail.yahoo.com> Message-ID: <15856.33313.767379.91681@lisa.tux4web.de> Hi Eric, I'll have to look into this in more detail some other time. I'm sorry... Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Dec 6 11:28:42 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 6 Dec 2002 12:28:42 +0100 Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release In-Reply-To: <15856.29076.236315.68786@lisa.tux4web.de> References: <20021205234644.7881.qmail@web11001.mail.yahoo.com> <20021205235904.92770.qmail@web11007.mail.yahoo.com> <15856.29076.236315.68786@lisa.tux4web.de> Message-ID: <15856.35306.592648.707677@lisa.tux4web.de> Hi Eric, actually you were right about this: >># float point quantities >>float, floatColumn = _float, _floatColumn >>numeric, numericColumn = _float, _floatColumn >No, that's not the way I wanted to go. The PostgreSQL NUMBERIC type >is for arbitrary precision quanteties, see, the the Python float type >has 64 bit (I think). 64 bit's pretty large, but it's not arbitrary. >I was going to use the egenix-experimental mx.Number class to >represent arbitrary numerals in ORM. The problem is, it doesn't >compile out-of-the-box on my maching (MacOSX). psycopg returns NUMERIC columns as floats. It does not make sense at all to let orm use mx.Number.Float, because on the way back from the database the numbers get converted to Python floats. I have added a line numeric, numericColumn = float, floatColumn to adapters.pgsql.columns that should do the job. As you know a float point number is not what you want to use for monetary arithmetic. You might want to use integers describing the number of cents or PostgreSQL's MONEY type. The latter, btw, comes back as a string from the database like this: "$100,25" but at least the SQL internal math should work. Perhaps it would make sense to create a money datatype that implements Python's number interface i.e. has __add__, __sub__ etc. Methods so it can be used just like normal numbers in Python. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Dec 6 11:59:08 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Fri, 6 Dec 2002 12:59:08 +0100 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <20021205051639.06854763B@pinky.miranda> References: <15849.64210.947371.650968@lisa.tux4web.de> <20021205051639.06854763B@pinky.miranda> Message-ID: <15856.37132.461537.800130@lisa.tux4web.de> Hi Julio, >ds= datasource(driver="pgsql", user="me", >password="thispassword",dbname="test",host="myhost") >ds1= datasource(driver="mysql", user="me", >password="thispassword",dbname="test",host="myhost") I decided to use the PostgreSQL style DSN notation for connection strings. Thanks to the genius of Guido van Rossum however, your idea was so easy to implement, that I just couldn't resist ;-) Here's the new docstring for that datasource function: """ Return a ORM datasource object constructed from a connection string or a number of keyword arguments. The connection strings follow the conventions for PostgreSQL DSNs: they consist of keyword=value pairs seperated with whitespace. Keywords recognized are: adapter - name of the ORM adapter used. Use the name from the adapters/ directory. db - name of the database to connect to user - Database username password - Password used for authentication host - hostname or IP address of the machine the database runs on (note that there might be a difference if you use 127.0.0.1 or localhost. The first creating a tcp/ip connection, the latter a unix/fifo connection. This is true for at leas pgsql and mysql Each of the database backends may define its own keywords. For instance PostgreSQL will understand each of the original keywords as aliases. Check the documentation! Values may not contain spaces. If you prefer to use the keyword argument syntax, the paramters must be the keyword and the argument the value: datasource('db=test user=diedrich password=kfjdh') equals datasource(db='test', user='diedrich', password='kfjdh') """ Believe it or not: only 2 lines (in words: two) had to be changed to implement this. I just **love** Python! >Ok, just a little idea, (you can flame me if you want ;-P No flames, please! Being arctic animals my penguins don't take heat very well :o) Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Fri Dec 6 22:35:54 2002 From: orm-devel@mailman.tux4web.de (Admin) Date: 06 Dec 2002 22:35:54 +0000 Subject: [orm-devel] Re: ORM In-Reply-To: <15856.30532.3302.286222@lisa.tux4web.de> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> Message-ID: <1039214154.10215.124.camel@eeyore> On Fri, 2002-12-06 at 10:09, Diedrich Vorberg wrote: > Hi Uwe, > > for a moment I though you to be Austrian, with that German name and > all. But after checking I figured you're not only across the Alps but > even Down Under... Yep, you guessed it I'm German. At least I was when I was borne. I've been down under since I was 2. My parent emigrated, I didn't get a vote. snip... > > Can orm be used to create the tables based on the column defs? > No. Mike Watkins sent a program in that goes the other way 'round and > creates orm's class definitions from the SQL layout. Check the > contrib/ directory. > Are there any plans to implement this. I can see numerous advantages in the python class being able to create the tables if required. Table versioning (MODIFY TABLE) could also be implemented allowing the source to control the data. This was one feature that I would have loved as data structures were always morphing over time and having to manhandle the restructuring of data is always painful. > There's no such thing as a silly question, just silly answers. You > have nearly as much programming experience as I am old ;-) If there > is any advise or suggestions from your side, I'm eager to hear them! Age is only a number. Experience broadens your view but also makes you cynical. I've seen this industry move from simplicity where almost anyone could pick up programming to a complex array of technologies where programmers are having to specialize. I've worked with most languages (Assembler, C, Basic, Cobol, Fortran, Forth, Pascal, Ada, PL/1, Clipper, Clarion and more) at one time or another and I find Python to be one of the most elegant. I'm going to have a play with orm and I'll pass on whatever I can. How about CREATE TABLE and MODIFY TABLE handling? > BTW: what are 4GL's? 4GL's were all the rage around 20 years ago and included packages like Clarion, FoxPro, Clipper, 4D and many others. Some are still evolving and quite popular although they are proprietary (evil?). They are mini-languages, that incorporate as much functionality in the base language as possible. Clarion for instance handled screen IO (UI) disk IO (database) and business logic in a language that was a mish-mash of Pascal, Cobol and Basic. They were never real fast but they did the job. With Clarion I wrote a complete integrated multi-user accounting system in 2 months and a Point-of-Sale add on for it in 8 days. Both packages are still in daily use. My next trick is to rewrite my packages using Python as Open Source, and set them free. I look forward to using orm in this process. Yours, Uwe. From orm-devel@mailman.tux4web.de Fri Dec 6 14:59:37 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 6 Dec 2002 06:59:37 -0800 (PST) Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) In-Reply-To: <15856.29076.236315.68786@lisa.tux4web.de> Message-ID: <20021206145937.19167.qmail@web11002.mail.yahoo.com> Hi Diedrich, --- Diedrich Vorberg wrote: > >> psycopg.ProgrammingError: ERROR: parser: parse error at or near "=<" > >> UPDATE projects SET job_number='2002-057', [snip other columns], > >> bid_price=, city='San > >> Francisco' > >> WHERE id=315 > > I don't seem to be able to reproduce this. Could you take a look at > the assignment of the new value? Do you assign a float number or a > column instance? Perhaps just cut and paste the code ... So you are able to commit numerical data types to postgres? The number is cast to a float before I try to commit it (see wxPython code snippet below). If you're not familiar with wxPython, the .GetValue() methods return string data: def OnSave(self, event): # don't bother with the id self.project.job_number = self.job_number.GetValue() #Special Date handling if self.project_date.GetValue() != "": self.project.project_date = \ Parser.DateFromString( \ self.project_date.GetValue()) self.project.name = self.name.GetValue() self.project.contacts_id = \ self.contacts_id.GetClientData( \ self.contacts_id.GetSelection()) self.project.project_type = \ self.project_type.GetStringSelection() # TODO: Fix the problem committing floats! self.project.bid_price = float(self.bid_price.GetValue()) self.project.address = self.address.GetValue() self.project.city = self.city.GetValue() self.project.state = self.state.GetValue() self.project.zip = self.zip.GetValue() if self.DoInsert: self.ds.insert(self.contact) # Commit the modified project to the database self.ds.commit() __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From orm-devel@mailman.tux4web.de Fri Dec 6 14:59:37 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 6 Dec 2002 06:59:37 -0800 (PST) Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) In-Reply-To: <15856.29076.236315.68786@lisa.tux4web.de> Message-ID: <20021206145937.19167.qmail@web11002.mail.yahoo.com> Hi Diedrich, --- Diedrich Vorberg wrote: > >> psycopg.ProgrammingError: ERROR: parser: parse error at or near "=<" > >> UPDATE projects SET job_number='2002-057', [snip other columns], > >> bid_price=, city='San > >> Francisco' > >> WHERE id=315 > > I don't seem to be able to reproduce this. Could you take a look at > the assignment of the new value? Do you assign a float number or a > column instance? Perhaps just cut and paste the code ... So you are able to commit numerical data types to postgres? The number is cast to a float before I try to commit it (see wxPython code snippet below). If you're not familiar with wxPython, the .GetValue() methods return string data: def OnSave(self, event): # don't bother with the id self.project.job_number = self.job_number.GetValue() #Special Date handling if self.project_date.GetValue() != "": self.project.project_date = \ Parser.DateFromString( \ self.project_date.GetValue()) self.project.name = self.name.GetValue() self.project.contacts_id = \ self.contacts_id.GetClientData( \ self.contacts_id.GetSelection()) self.project.project_type = \ self.project_type.GetStringSelection() # TODO: Fix the problem committing floats! self.project.bid_price = float(self.bid_price.GetValue()) self.project.address = self.address.GetValue() self.project.city = self.city.GetValue() self.project.state = self.state.GetValue() self.project.zip = self.zip.GetValue() if self.DoInsert: self.ds.insert(self.contact) # Commit the modified project to the database self.ds.commit() __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From orm-devel@mailman.tux4web.de Fri Dec 6 15:19:47 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 06 Dec 2002 07:19:47 -0800 Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) Message-ID: <3DF0C013.3090702@ericwalstad.com> Ugh, Yahoo clipped the bottom of my message again. I've changed my list subscription to point to my usual mail reader now, sorry for the inconvenience. I simply asked for any tips on where to start looking for the problem. In the mean time, I'll try to build a reproduceable test case that isolates the problem. Thanks again for your time. Best regards, Eric. From orm-devel@mailman.tux4web.de Fri Dec 6 15:38:42 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Fri, 6 Dec 2002 09:38:42 -0600 Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release In-Reply-To: <15856.35306.592648.707677@lisa.tux4web.de> References: <20021205234644.7881.qmail@web11001.mail.yahoo.com> <20021205235904.92770.qmail@web11007.mail.yahoo.com> <15856.29076.236315.68786@lisa.tux4web.de> <15856.35306.592648.707677@lisa.tux4web.de> Message-ID: <20021206153842.GA30450@wallace.ece.rice.edu> On Fri, Dec 06, 2002 at 12:28:42PM +0100, Diedrich Vorberg wrote: > > As you know a float point number is not what you want to use for > monetary arithmetic. You might want to use integers describing the > number of cents or PostgreSQL's MONEY type. The latter, btw, comes > back as a string from the database like this: > > "$100,25" > > but at least the SQL internal math should work. Ack, no - the money type is depricated, and will disappear in 7.4. The right answer is to extend psycopg to 'do the right thing' (perhaps as a option?) with the numeric type. Your original idea of using a python extension numeric type sounds right to me. Ross From orm-devel@mailman.tux4web.de Fri Dec 6 16:06:50 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Fri, 6 Dec 2002 10:06:50 -0600 Subject: [orm-devel] Re: ORM In-Reply-To: <1039214154.10215.124.camel@eeyore> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> Message-ID: <20021206160650.GB30450@wallace.ece.rice.edu> On Fri, Dec 06, 2002 at 10:35:54PM +0000, Admin wrote: > > 4GL's were all the rage around 20 years ago and included packages like > Clarion, FoxPro, Clipper, 4D and many others. Some are still evolving > and quite popular although they are proprietary (evil?). They are > mini-languages, that incorporate as much functionality in the base > language as possible. Clarion for instance handled screen IO (UI) disk > IO (database) and business logic in a language that was a mish-mash of > Pascal, Cobol and Basic. They were never real fast but they did the job. > With Clarion I wrote a complete integrated multi-user accounting system > in 2 months and a Point-of-Sale add on for it in 8 days. Both packages > are still in daily use. > > My next trick is to rewrite my packages using Python as Open Source, > and set them free. > > I look forward to using orm in this process. Not to chase you away, or anything, but I think you might want to take a look at the GNUe project, as well as ORM: it's targetted more at the 'all singing, all dancing' sort of system your talking about. My understanding of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's light weight - it's a membrane, not an entire layer. I'd be concerned about blowing it up with functions like database schema management - it'd lose it's lightness, I'm afraid. GNUe (which is also python based), on the other hand, takes an approach much like you've suggested above: the 'middleware' handles all the database work. It's developers come out of your world of 4GLs and SQL*Reports and such - take a look at http://www.gnuenterprise.org. To date, they've focused on building tools, but they've plans for packages (like POS or CR) as well. To get a real flavor of who the developers are and where things are at, there's a weekly 'news summary' of the development lists (and IRC logs) at http://kt.zork.net/GNUe/latest.html Deidrich, you might even want to take a look at what they're doing - it's a different approach, but sometimes ideas can cross-fertilize. They're all young and energetic, too. ;-) Ross From orm-devel@mailman.tux4web.de Fri Dec 6 16:11:34 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Fri, 6 Dec 2002 10:11:34 -0600 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <15856.37132.461537.800130@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> <20021205051639.06854763B@pinky.miranda> <15856.37132.461537.800130@lisa.tux4web.de> Message-ID: <20021206161134.GC30450@wallace.ece.rice.edu> On Fri, Dec 06, 2002 at 12:59:08PM +0100, Diedrich Vorberg wrote: > > >Ok, just a little idea, (you can flame me if you want ;-P > No flames, please! Being arctic animals my penguins don't take heat > very well :o) Diedrich, penguins are _antarctic_ animals: everyone _knows_ the polar bears would eat them if they ever got into the artic! ;-) Ross Well, I suppose you meant 'arctic', not 'Arctic', as in 'cold dwelling animals' not 'animals that live north of the Arctic circle', so ignore this troll/flame. ;-) From orm-devel@mailman.tux4web.de Fri Dec 6 17:20:41 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 06 Dec 2002 09:20:41 -0800 Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) In-Reply-To: <3DF0C013.3090702@ericwalstad.com> References: <3DF0C013.3090702@ericwalstad.com> Message-ID: <3DF0DC69.9090600@ericwalstad.com> Deidrich, I think I found the problem... in orm/columns.py at line 547: # float point quantities float, floatColumn = _float, _floatColumn The "float" above must be a Python reserved word, which is resulting in the orm.column._float instance being committed to the database. If I modify orm/columns.py like this: # float point quantities orm_float, floatColumn = _float, _floatColumn And then I change my dbclass table definition from "bid_price : float()" to "bid_price : orm_float()" It works like a charm :) Thanks to the python syntax highlighting of the Kate editor for flagging "float" for me. Best, Eric. From orm-devel@mailman.tux4web.de Fri Dec 6 17:33:33 2002 From: orm-devel@mailman.tux4web.de (Mike Watkins) Date: Fri, 06 Dec 2002 09:33:33 -0800 Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) In-Reply-To: <3DF0DC69.9090600@ericwalstad.com> References: <3DF0C013.3090702@ericwalstad.com> <3DF0C013.3090702@ericwalstad.com> Message-ID: <5.1.0.14.0.20021206093231.02091ec0@mail.mikewatkins.net> At 09:20 AM 12/6/2002 -0800, you wrote: >I think I found the problem... >in orm/columns.py at line 547: > ># float point quantities >float, floatColumn = _float, _floatColumn > >The "float" above must be a Python reserved word, which is resulting in >the orm.column._float instance being committed to the database. Yup, that's certainly it. float is a built-in type. >>> float Good sleuthing! From orm-devel@mailman.tux4web.de Sat Dec 7 09:31:28 2002 From: orm-devel@mailman.tux4web.de (Admin) Date: 07 Dec 2002 09:31:28 +0000 Subject: [orm-devel] Introduction, thanks and a couple of comments on the 0.7 release In-Reply-To: <15856.35306.592648.707677@lisa.tux4web.de> References: <20021205234644.7881.qmail@web11001.mail.yahoo.com> <20021205235904.92770.qmail@web11007.mail.yahoo.com> <15856.29076.236315.68786@lisa.tux4web.de> <15856.35306.592648.707677@lisa.tux4web.de> Message-ID: <1039253488.15269.14.camel@eeyore> > As you know a float point number is not what you want to use for > monetary arithmetic. You might want to use integers describing the > number of cents or PostgreSQL's MONEY type. The latter, btw, comes > back as a string from the database like this: > > "$100,25" > > but at least the SQL internal math should work. > PostgreSQL's MONEY type has been deprecated, we are advised to use NUMERIC or DECIMAL. From orm-devel@mailman.tux4web.de Sat Dec 7 01:07:20 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 02:07:20 +0100 Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) In-Reply-To: <3DF0DC69.9090600@ericwalstad.com> References: <3DF0C013.3090702@ericwalstad.com> <3DF0DC69.9090600@ericwalstad.com> Message-ID: <15857.18888.785289.600037@lisa.tux4web.de> Hi, >I think I found the problem... >It works like a charm :) you are right! Nice sleuthing(*) indeed! This never occurred to me, because I keep my model in a seperate module. I'm a little reluctant to change the identifyer, because it would break the overall naming scheme. Can you live with seperating the dbclass' definition in another module? Alternatively you could from orm.columns import float as orm_float On the other hand this is a subtle pitfall for anyone working with orm. If someone does # model.py from orm.columns import * ... # program.py from model import * he's got the same problem.... I'll think some about it. Do you guys have to do a lot of modifications if the float type is renamed? Diedrich (*) learned a new word today. Say Mike... is this Canadian? :-) -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sat Dec 7 01:08:50 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 02:08:50 +0100 Subject: MONEY (was: Re: [orm-devel] Introduction, thanks and ...) the 0.7 release In-Reply-To: <1039253488.15269.14.camel@eeyore> References: <20021205234644.7881.qmail@web11001.mail.yahoo.com> <20021205235904.92770.qmail@web11007.mail.yahoo.com> <15856.29076.236315.68786@lisa.tux4web.de> <15856.35306.592648.707677@lisa.tux4web.de> <1039253488.15269.14.camel@eeyore> Message-ID: <15857.18978.29275.250681@lisa.tux4web.de> >PostgreSQL's MONEY type has been deprecated, we are advised to use >NUMERIC or DECIMAL. Yes, this was silly... From orm-devel@mailman.tux4web.de Sat Dec 7 01:23:32 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 02:23:32 +0100 Subject: [orm-devel] NUMERICAL and DECIMAL on the Python side Message-ID: <15857.19860.766742.801785@lisa.tux4web.de> Hallo, I've read some of psycopg's sourcecode and found that it has a very flexible type system which can be extended in such a way that you can map PostgreSQL types to custom Python classes. float was chosen for NUMERIC and DECIMAL to keep the number of psycopg's dependencies at a minimum. See Federico Di Gregorio's statement on http://lists.initd.org/pipermail/psycopg/2002-April/000991.html In the same thread on the psycopg list someone suggest the FixedPoint module as a storage class for these SQL Types on the Python side. See http://fixedpoint.sourceforge.net/html/lib/module-FixedPoint.html for more on this one. For financial calculations this seems to be the way to go. I do not really know whether it is well suited for math with really big quantities as are NUMERIC and DECIMAL. mx.Number looks like a good solution for that. I guess we need to take both packages into account. Does anyone on this list know of any other packages for exact arbitrary precision math that matches the SQL types better? Also, I wonder how good these extra dependencies are for orm... Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sat Dec 7 01:59:23 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 02:59:23 +0100 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <20021206160650.GB30450@wallace.ece.rice.edu> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> Message-ID: <15857.22011.760583.23330@lisa.tux4web.de> Hi Ross, Hi Uwe and everyone else! >> My next trick is to rewrite my packages using Python as Open Source, >> and set them free. Wow, I'm impressed! >> I look forward to using orm in this process. I hope orm will be able to meet your needs! >Not to chase you away, or anything, but I think you might want to take a >look at the GNUe project, as well as ORM: it's targetted more at the 'all >singing, all dancing' sort of system your talking about. My understanding >of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's >light weight - it's a membrane, not an entire layer. I'd be concerned about >blowing it up with functions like database schema management - it'd lose >it's lightness, I'm afraid. I can see the point Ross' is making here. ORM is supposed to be a smart helper not a grown up middleware framework. However, depending on how sophisticated the table modification mechanism is supposed to be, it might not be very hard to write and it might not even outgrow its writer. A module that contains all the dbclasses is basically a description of the SQL table's layout as a Python datastructure. If you'd write a program that would import that module, look at the model it describes and then creates the SQL to adapt the tables to that model you basically have got the thing you are looking for. I'd not necessaryly code it directly into the datasource class but as a seperate module this could make sense, I think. The module might export a class like... er... from orm.model_manager import ModelManager mm = ModelManager(my_datasource) # you'll need a life connection and then: # define or import my dbclasses... mm.register(customer) mm.register(address) or import beans mm.registerModule(beans) # the whole model in one module and then: mm.checkTables(raise=1) # just print warnings about modifications or raise exceptions if # things won't work out or mm.correctTables(drop=0) # execute SQL commands to adjust the tables to the model # drop=1 will execute commands as MODIFY TABLE DROP COLUMN # drop=0 will not destroy any data, just warn (and maybe suggest # appropriate SQL statements) I think it is important however, that this mechanism considers itself subordinate to a programmer who knows his SQL basics. In other words, it should be transparent what's going on. (Unless the programmer deliberately turns that off) I could imagine a mm.suggest() method that will print the SQL statements correctTables() would execute allong with some commentary. Also there should be a mechanism to exclude tables from the process. An attribute in each dbclass will do: class person(dbclass): manage_manually = 1 Programmers who use orm in the 'classic' way do not even have to know about this. Uwe, if you feel like giving this a try I'll try to provide all the help you need plus (this a good part of the deal :-) an account on an old hp9000 workstation a couple of thousand miles away from you. >Deidrich, you might even want to take a look at what they're doing - it's >a different approach, but sometimes ideas can cross-fertilize. They're >all young and energetic, too. ;-) Yes, I will! I was looking at there website some time ago and didn't find any code. That was before I even knew Python and they really started. What I read on the page looks very promising. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sat Dec 7 13:58:38 2002 From: orm-devel@mailman.tux4web.de (Uwe (Peter) Feldtmann) Date: 07 Dec 2002 13:58:38 +0000 Subject: [orm-devel] Re: ORM In-Reply-To: <20021206160650.GB30450@wallace.ece.rice.edu> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> Message-ID: <1039269518.15330.30.camel@eeyore> Hi Ross, > Not to chase you away, or anything, but I think you might want to take a > look at the GNUe project, as well as ORM: it's targetted more at the 'all > singing, all dancing' sort of system your talking about. My understanding > of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's > light weight - it's a membrane, not an entire layer. I'd be concerned about > blowing it up with functions like database schema management - it'd lose > it's lightness, I'm afraid. > I agree with you that we shouldn't detract from ORM's original goals, however, a separate data manager class responsible for tables that uses ORM might be a nice addition to the library. The same class could be further extended to provide additional info for field sizes (UI) etc. > GNUe (which is also python based), on the other hand, takes an approach > much like you've suggested above: the 'middleware' handles all the > database work. It's developers come out of your world of 4GLs and > SQL*Reports and such - take a look at http://www.gnuenterprise.org. To > date, they've focused on building tools, but they've plans for packages > (like POS or CR) as well. To get a real flavor of who the developers > are and where things are at, there's a weekly 'news summary' of the > development lists (and IRC logs) at http://kt.zork.net/GNUe/latest.html > I've been following GNUe for 2 years now as I too thought it would be a good starting point for my apps. GNUe might eventually be an ideal tool set for enterprise apps, however, most of my end users are SME's and require simpler (to administer) applications. That's why they bought my apps in the first place. > Deidrich, you might even want to take a look at what they're doing - it's > a different approach, but sometimes ideas can cross-fertilize. They're > all young and energetic, too. ;-) Good idea but try not to get side tracked. Uwe. From orm-devel@mailman.tux4web.de Sat Dec 7 04:07:57 2002 From: orm-devel@mailman.tux4web.de (Julio Rommi =?iso-8859-1?q?O=F1a=20Miranda?=) Date: Sat, 7 Dec 2002 00:07:57 -0400 Subject: [orm-devel] Unified Connection Strings In-Reply-To: <15856.37132.461537.800130@lisa.tux4web.de> References: <15849.64210.947371.650968@lisa.tux4web.de> <20021205051639.06854763B@pinky.miranda> <15856.37132.461537.800130@lisa.tux4web.de> Message-ID: <20021207040932.0EB188632@pinky.miranda> Hi Diedrich!!, El Vie 06 Dic 2002 07:59, escribió: > Believe it or not: only 2 lines (in words: two) had to be changed to > implement this. I just **love** Python! > That is so impresive!!!!! I really think python is a powerful idea (not only a language). By the way, ORM is evolving really fast, I'ts leaving me back!!!. I mean I just have some time trying to get selectors ready to publish, but with no luck (just no time), I will try to take it ready this weekend, I hope ;-) Well, KUDOS! -- Julio From orm-devel@mailman.tux4web.de Sat Dec 7 14:06:04 2002 From: orm-devel@mailman.tux4web.de (Admin) Date: 07 Dec 2002 14:06:04 +0000 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <15857.22011.760583.23330@lisa.tux4web.de> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> Message-ID: <1039269964.15330.38.camel@eeyore> Hi all, > >> My next trick is to rewrite my packages using Python as Open Source, > >> and set them free. > Wow, I'm impressed! If I ever get it done I'll be relieved. > >Not to chase you away, or anything, but I think you might want to take a > >look at the GNUe project, as well as ORM: it's targetted more at the 'all > >singing, all dancing' sort of system your talking about. My understanding > >of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's > >light weight - it's a membrane, not an entire layer. I'd be concerned about > >blowing it up with functions like database schema management - it'd lose > >it's lightness, I'm afraid. > > I can see the point Ross' is making here. ORM is supposed to be a > smart helper not a grown up middleware framework. However, depending > on how sophisticated the table modification mechanism is supposed to > be, it might not be very hard to write and it might not even outgrow > its writer. > > A module that contains all the dbclasses is basically a description > of the SQL table's layout as a Python datastructure. If you'd write a > program that would import that module, look at the model it describes > and then creates the SQL to adapt the tables to that model you > basically have got the thing you are looking for. > > I'd not necessaryly code it directly into the datasource class but as > a seperate module this could make sense, I think. The module might > export a class like... er... > > from orm.model_manager import ModelManager > mm = ModelManager(my_datasource) # you'll need a life connection > > and then: > > # define or import my dbclasses... > mm.register(customer) > mm.register(address) > > or > > import beans > mm.registerModule(beans) # the whole model in one module > > and then: > > mm.checkTables(raise=1) > # just print warnings about modifications or raise exceptions if > # things won't work out > > or > > mm.correctTables(drop=0) > # execute SQL commands to adjust the tables to the model > # drop=1 will execute commands as MODIFY TABLE DROP COLUMN > # drop=0 will not destroy any data, just warn (and maybe suggest > # appropriate SQL statements) > > I think it is important however, that this mechanism considers itself > subordinate to a programmer who knows his SQL basics. In other words, > it should be transparent what's going on. (Unless the programmer > deliberately turns that off) I could imagine a > > mm.suggest() > > method that will print the SQL statements correctTables() would > execute allong with some commentary. Also there should be a mechanism > to exclude tables from the process. An attribute in each dbclass will > do: > > class person(dbclass): > manage_manually = 1 > > Programmers who use orm in the 'classic' way do not even have to know > about this. > You've almost written it already! > Uwe, if you feel like giving this a try I'll try to provide all the > help you need plus (this a good part of the deal :-) an account on an > old hp9000 workstation a couple of thousand miles away from you. > I might just take you up on this when I get some code happening. Uwe. From orm-devel@mailman.tux4web.de Sat Dec 7 04:18:26 2002 From: orm-devel@mailman.tux4web.de (Mike Watkins) Date: Fri, 06 Dec 2002 20:18:26 -0800 Subject: [orm-devel] Numeric/float prob committing (was: Introduction, thanks and a couple of comments on the 0.7 release) In-Reply-To: <15857.18888.785289.600037@lisa.tux4web.de> References: <3DF0DC69.9090600@ericwalstad.com> <3DF0C013.3090702@ericwalstad.com> <3DF0DC69.9090600@ericwalstad.com> Message-ID: <5.1.0.14.0.20021206201628.0208f830@mail.mikewatkins.net> The word sleuth makes me think of Sir Arthur and Sherlock Holmes, so probably its English rather than Canadian... eh? (its said that Canadians use the 'word' "eh?" frequently in conversation. I've never noticed that, eh? :-) At 02:07 AM 12/7/2002 +0100, you wrote: >you are right! Nice sleuthing(*) indeed! From orm-devel@mailman.tux4web.de Sat Dec 7 04:41:24 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 05:41:24 +0100 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) Message-ID: <15857.31732.683352.431293@lisa.tux4web.de> Good evening Eric! Hi Ross, Julio and Mike! You guys still up? A good afternoon Uwe! And to those Europeans who got an early start or didn't bother to go sleep: a very good morning to you! It's 5 A.M. now and I think it was worth it ;-) This is how it works: o PostgreSQL returns its results SQL literals contained in strings o psycopg parses these strings and makes them Python objects o to do so it employs a well designed and very pythonesqe (same thing really) mechanism o the conversion of NUMERIC(sql) to float(py) is just a default and can be changed o I modified the pgsql.datasource so that it does just that. Now pgsql will return strings(py) for each SQL datatype that enherits from orm.adapters.pgsql.column.customType o orm's convert()/format() mechanism takes care of converting these strings to the right Python objects now o I've created a numeric datatype and a numericColumn. They use the FixedPoint module you can find at http://fixedpoint.sourceforge.net/html/lib/module-FixedPoint.html This lets you use arbitrary precision/exact math just like pgsql does internally. The best thing about it: I didn't have to mess up the code :-) Check out the new version from CVS and, if time permits, do some testing! As you can plainly see, I'm having a great time working with you and I really dig this Free Software thing now. I liked the idea before, but now I dig it ;-) Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sat Dec 7 06:01:06 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 06 Dec 2002 22:01:06 -0800 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <15857.22011.760583.23330@lisa.tux4web.de> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> Message-ID: <3DF18EA2.6040404@ericwalstad.com> Diedrich Vorberg wrote: >>Not to chase you away, or anything, but I think you might want to take a >>look at the GNUe project, as well as ORM: it's targetted more at the 'all >>singing, all dancing' sort of system your talking about. My understanding >>of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's >>light weight - it's a membrane, not an entire layer. I'd be concerned about >>blowing it up with functions like database schema management - it'd lose >>it's lightness, I'm afraid. > > > I can see the point Ross' is making here. ORM is supposed to be a > smart helper not a grown up middleware framework. However, depending > on how sophisticated the table modification mechanism is supposed to > be, it might not be very hard to write and it might not even outgrow > its writer. I'd stay away from the idea of making orm do schema management. My fear would be that adding this kind of feature set would make orm bloated and cumbersome. I also think that schema management is best left to the db supplier (or other third parties that specialize in it). I generally put a lot of thought and time into designing a schema that will efficiently model the problem domain. Actually building the tables takes up only a small portion of this time. I really *hate* changing the schema once the entities/tables have been created - the ability to have orm do it for me doesn't sound very interesting. Best regards, Eric. From orm-devel@mailman.tux4web.de Sat Dec 7 06:04:44 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 06 Dec 2002 22:04:44 -0800 Subject: [orm-devel] [Off Topic] Eh (was: Numeric/float prob committing) In-Reply-To: <5.1.0.14.0.20021206201628.0208f830@mail.mikewatkins.net> References: <3DF0DC69.9090600@ericwalstad.com> <3DF0C013.3090702@ericwalstad.com> <3DF0DC69.9090600@ericwalstad.com> <5.1.0.14.0.20021206201628.0208f830@mail.mikewatkins.net> Message-ID: <3DF18F7C.2080504@ericwalstad.com> Hi Mike. I've heard Canada is spelled: C - eh - N - eh - D - eh Heehee. Respectfully, Eric. Mike Watkins wrote: > The word sleuth makes me think of Sir Arthur and Sherlock Holmes, so > probably its English rather than Canadian... > > eh? > > (its said that Canadians use the 'word' "eh?" frequently in > conversation. I've never noticed that, eh? > > :-) From orm-devel@mailman.tux4web.de Sat Dec 7 16:21:45 2002 From: orm-devel@mailman.tux4web.de (Uwe (Peter) Feldtmann) Date: 07 Dec 2002 16:21:45 +0000 Subject: [orm-devel] Re: ORM In-Reply-To: <15856.30532.3302.286222@lisa.tux4web.de> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> Message-ID: <1039278105.15330.115.camel@eeyore> Hi all, > > Can orm be used to create the tables based on the column defs? > No. Mike Watkins sent a program in that goes the other way 'round and > creates orm's class definitions from the SQL layout. Check the > contrib/ directory. > Had a quick look. Does anyone know why psycopg doesn't import column types in cursor.description? I'll ask them on their list as well. I haven't tested this, as I don't have pyPgSQL, but if the following lines are modified it would be easier to spot what requires attention for relationships in the generated code. snip.. if colname.find('_id') > 0: colclass = "relates_to(%s)" % colname.split('_')[0] snip.. The above should result in "category_id": relates_to(category) If only we could find a notation for the various relationships that wouldn't clutter up the defs. Uwe. From orm-devel@mailman.tux4web.de Sat Dec 7 06:27:16 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Fri, 06 Dec 2002 22:27:16 -0800 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) In-Reply-To: <15857.31732.683352.431293@lisa.tux4web.de> References: <15857.31732.683352.431293@lisa.tux4web.de> Message-ID: <3DF194C4.5070305@ericwalstad.com> Diedrich Vorberg wrote: > Good evening Eric! Good Morning! Wow, an all-nighter! You-da-man! :) (My 3yr old daughter won't let me do all-nighter's any more) > This is how it works: > > o PostgreSQL returns its results SQL literals contained in strings > o psycopg parses these strings and makes them Python objects > o to do so it employs a well designed and very pythonesqe (same > thing really) mechanism > o the conversion of NUMERIC(sql) to float(py) is just a default and > can be changed > o I modified the pgsql.datasource so that it does just that. Now > pgsql will return strings(py) for each SQL datatype that enherits > from orm.adapters.pgsql.column.customType > o orm's convert()/format() mechanism takes care of converting these > strings to the right Python objects now > o I've created a numeric datatype and a numericColumn. They use the > FixedPoint module you can find at > > http://fixedpoint.sourceforge.net/html/lib/module-FixedPoint.html > > This lets you use arbitrary precision/exact math just like pgsql > does internally. > > The best thing about it: I didn't have to mess up the code :-) Hey, that sounds like a nice solution. If I understand you correctly, I can choose to use the new numeric/Column type (and install and use FixedPoint) or I can choose to use customType and handle any needed conversions myself? I don't care to use FixedPoint ( I don't know anything about it, and I may change my mind later, but for now I crave simplicity ). Is FixedPoint now a requirement of orm? > Check out the new version from CVS and, if time permits, do some > testing! I will, and I'll report back what I find. Probably by next Tuesday. > As you can plainly see, I'm having a great time working with you and > I really dig this Free Software thing now. I liked the idea before, > but now I dig it ;-) I second that! I whetted my OSS appetite on ecoaccess.org (appears to be down now?) which is where I worked on my not-quite-as-fancy-pants-as-orm classes for a Task Management system. That was my first stab at working on a distributed OSS team and I really enjoyed it and learned a *lot*. I hope I can help out with orm as it's already helping me. I wish I could earn at least a meager living doing it - nothing is as nice as loving your work... Well, ok, there are a few things nicer ;^) Best regards, Eric. From orm-devel@mailman.tux4web.de Sat Dec 7 06:29:45 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 07:29:45 +0100 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <3DF18EA2.6040404@ericwalstad.com> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> <3DF18EA2.6040404@ericwalstad.com> Message-ID: <15857.38233.302588.875033@lisa.tux4web.de> Hi Ross, >I'd stay away from the idea of making orm do schema management. My fear >would be that adding this kind of feature set would make orm bloated and >cumbersome. I also think that schema management is best left to the db >supplier (or other third parties that specialize in it). I generally >put a lot of thought and time into designing a schema that will >efficiently model the problem domain. Actually building the tables >takes up only a small portion of this time. I really *hate* changing >the schema once the entities/tables have been created - the ability to >have orm do it for me doesn't sound very interesting. If this is done it has to stay in a module of its own and should not make changes to any other part of orm necessary. With that requirement met I don't see any harm done. I can see side how it could be usefull for some. Personally I change around the tables a bit but that usually means changing the app, too. The effort bringing orm up-to-date with the SQL is dwarfed by the work spent on that. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sat Dec 7 16:32:32 2002 From: orm-devel@mailman.tux4web.de (Admin) Date: 07 Dec 2002 16:32:32 +0000 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) In-Reply-To: <15857.31732.683352.431293@lisa.tux4web.de> References: <15857.31732.683352.431293@lisa.tux4web.de> Message-ID: <1039278752.15330.123.camel@eeyore> He who never sleeps has done it again! Uberhacker? > Good evening Eric! > Hi Ross, Julio and Mike! You guys still up? > A good afternoon Uwe! > And to those Europeans who got an early start or didn't bother to go > sleep: a very good morning to you! > > It's 5 A.M. now and I think it was worth it ;-) > > This is how it works: > > o PostgreSQL returns its results SQL literals contained in strings > o psycopg parses these strings and makes them Python objects > o to do so it employs a well designed and very pythonesqe (same > thing really) mechanism > o the conversion of NUMERIC(sql) to float(py) is just a default and > can be changed > o I modified the pgsql.datasource so that it does just that. Now > pgsql will return strings(py) for each SQL datatype that enherits > from orm.adapters.pgsql.column.customType > o orm's convert()/format() mechanism takes care of converting these > strings to the right Python objects now > o I've created a numeric datatype and a numericColumn. They use the > FixedPoint module you can find at > > http://fixedpoint.sourceforge.net/html/lib/module-FixedPoint.html > > This lets you use arbitrary precision/exact math just like pgsql > does internally. > > The best thing about it: I didn't have to mess up the code :-) > > Check out the new version from CVS and, if time permits, do some > testing! > > As you can plainly see, I'm having a great time working with you and > I really dig this Free Software thing now. I liked the idea before, > but now I dig it ;-) > From orm-devel@mailman.tux4web.de Sat Dec 7 06:39:05 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Sat, 7 Dec 2002 07:39:05 +0100 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) In-Reply-To: <3DF194C4.5070305@ericwalstad.com> References: <15857.31732.683352.431293@lisa.tux4web.de> <3DF194C4.5070305@ericwalstad.com> Message-ID: <15857.38793.483466.129648@lisa.tux4web.de> Hi Eric, >Hey, that sounds like a nice solution. If I understand you correctly, I >can choose to use the new numeric/Column type (and install and use >FixedPoint) or I can choose to use customType and handle any needed >conversions myself? I don't care to use FixedPoint ( I don't know >anything about it, and I may change my mind later, but for now I crave >simplicity ). Not quite. You'd have to write your own datatype/column pair, which probably isn't worth the effort. >Is FixedPoint now a requirement of orm? No it isn't. The import statement in orm.adapters.pgsql.datasource is in a try: block and the except: will define a minimal class FixedPoint which is a wraper around a Python string, really. If you only want the NUMERIC data as a string and simply use float() on it you can skip installing FixedPoint and use it this way. You might want to take a look, though, doesn't seem too bad. Perhaps I should have integrated the simple string functionality in CustomType as a default behaviour. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Sat Dec 7 16:44:00 2002 From: orm-devel@mailman.tux4web.de (Admin) Date: 07 Dec 2002 16:44:00 +0000 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <3DF18EA2.6040404@ericwalstad.com> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> <3DF18EA2.6040404@ericwalstad.com> Message-ID: <1039279440.15330.132.camel@eeyore> Hi Eric, I appreciate what your saying and I agree that ORM shouldn't do full on schema management. What I'm proposing is a way to minimize maintenance for us programmers. The way it stands at present we need to keep the ORM object and the SQL table defs in line manually. Mikes code could be enhanced, if we found a notation for relationships (see earlier post "Re: [orm-devel] Re: ORM"), to return the class def to ORM based on the table schema. Uwe. > Diedrich Vorberg wrote: > >>Not to chase you away, or anything, but I think you might want to take a > >>look at the GNUe project, as well as ORM: it's targetted more at the 'all > >>singing, all dancing' sort of system your talking about. My understanding > >>of Deidrich's vision/goals for ORM is that it's biggest virtue is in it's > >>light weight - it's a membrane, not an entire layer. I'd be concerned about > >>blowing it up with functions like database schema management - it'd lose > >>it's lightness, I'm afraid. > > > > > > I can see the point Ross' is making here. ORM is supposed to be a > > smart helper not a grown up middleware framework. However, depending > > on how sophisticated the table modification mechanism is supposed to > > be, it might not be very hard to write and it might not even outgrow > > its writer. > > I'd stay away from the idea of making orm do schema management. My fear > would be that adding this kind of feature set would make orm bloated and > cumbersome. I also think that schema management is best left to the db > supplier (or other third parties that specialize in it). I generally > put a lot of thought and time into designing a schema that will > efficiently model the problem domain. Actually building the tables > takes up only a small portion of this time. I really *hate* changing > the schema once the entities/tables have been created - the ability to > have orm do it for me doesn't sound very interesting. > > Best regards, > > Eric. > > _______________________________________________ > orm-devel mailing list > orm-devel@mailman.tux4web.de > http://mailman.tux4web.de/mailman/listinfo/orm-devel > From orm-devel@mailman.tux4web.de Sat Dec 7 16:15:01 2002 From: orm-devel@mailman.tux4web.de (Mike Watkins) Date: Sat, 07 Dec 2002 08:15:01 -0800 Subject: [orm-devel] Re: ORM In-Reply-To: <1039278105.15330.115.camel@eeyore> References: <15856.30532.3302.286222@lisa.tux4web.de> <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> Message-ID: <5.1.0.14.0.20021207081304.0208b450@mail.mikewatkins.net> I have a work around that uses pg_types table in Postgres, so you can use psycopg. Attached... Mike #!/usr/bin/python # generate_orm.py # (c) 2002 Mike Watkins # Anyone can use this for whatever they desire. # Generates (mostly) a complete class definition from the SQL tables. one2one, one2many etc relations # have to be hand inserted into the output of this. Requires that one row at least be in the table. # Example of a finished class: # # class subject(dbclass): # columns = { "id": serial(), # generate_orm will simply call this an integer() unless its labelled 'id' # "name": varchar(), # "detail": varchar() , # "category_id": one2one(category), # generate_orm will simply call this an integer() # "create_date": timestamp(), # "modified_date": timestamp() } # import sys # psycopg doesn't return the column types in cursor.description, pyPgSQL does # get it from http://pypgsql.sourceforge.net/ # from pyPgSQL import PgSQL # 2002-11-25 switched this to use psycopg, drawing the type info from pg_types import psycopg def output(table): pg_types = {} cursor.execute('select oid, typname from pg_type') result = cursor.fetchall() for r in result: pg_types[r[0]] = r[1] colname = colclass = '' classcomment = '# column(s): %s are candidates for one2one, one2many, etc, update manually' candidates = [] # get a row, colnames are in cursor.description select = "SELECT * FROM %s" % (table,) cursor.execute(select) row = cursor.fetchone() # print the basic class definition print """class %s(dbclass): columns = { """ % (table.title(),) first = True for column in cursor.description: if first: first = False else: print "," colname = column[0] colclass = pg_types[column[1]] if colname.find('_id') > 0: candidates.append(colname) # this mapping of classes and types to ORM objects (defined in relationships.py) is by no # means complete. I just don't use many different data types. if colname == 'id': colclass = 'serial' if colclass == 'bool': colclass = 'boolean' if colclass == 'int4': colclass = 'integer' print """ "%s" :%s%s()""" % (colname, (25 - len(colname) ) * ' ', colclass), print "\n }", if candidates: print classcomment % candidates, print "\n" if __name__ == "__main__": # only interested in one table? Specify it here or leave as None table = None # feel free to hard code your DSN in here DSN = 'YOUR OWN DSN HERE' print "# ORM unfinished classes automagically generated by orm_generate.py" print "# Cut and paste these into your code and update as required." print "# Opening connection using DSN: %s\n\n" % (DSN,) db = psycopg.connect(DSN) cursor = db.cursor() tables = [] if not table: cursor.execute("""select tablename from pg_tables where tablename not like 'pg_%' order by tablename""") result = cursor.fetchall() for r in result: tables.append(r[0]) else: tables.append(table) for table in tables: output(table) At 04:21 PM 12/7/2002 +0000, you wrote: >Had a quick look. Does anyone know why psycopg doesn't import column >types in cursor.description? I'll ask them on their list as well. > >I haven't tested this, as I don't have pyPgSQL, but if the following >lines are modified it would be easier to spot what requires attention >for relationships in the generated code. From orm-devel@mailman.tux4web.de Sat Dec 7 18:03:11 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Sat, 7 Dec 2002 12:03:11 -0600 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <15857.38233.302588.875033@lisa.tux4web.de> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> <3DF18EA2.6040404@ericwalstad.com> <15857.38233.302588.875033@lisa.tux4web.de> Message-ID: <20021207180310.GA8699@wallace.ece.rice.edu> On Sat, Dec 07, 2002 at 07:29:45AM +0100, Diedrich Vorberg wrote: > Hi Ross, Actually, the quoted text here was written by Eric Walstad. (though I agree with the sentiment;-) > >I'd stay away from the idea of making orm do schema management. My fear > >would be that adding this kind of feature set would make orm bloated and > >cumbersome. I also think that schema management is best left to the db > >supplier (or other third parties that specialize in it). I generally > >put a lot of thought and time into designing a schema that will > >efficiently model the problem domain. Actually building the tables > >takes up only a small portion of this time. I really *hate* changing > >the schema once the entities/tables have been created - the ability to > >have orm do it for me doesn't sound very interesting. > > If this is done it has to stay in a module of its own and should not > make changes to any other part of orm necessary. With that requirement > met I don't see any harm done. I can see side how it could be usefull > for some. Right, so it's almost an app _on top of_ orm. > Personally I change around the tables a bit but that usually means > changing the app, too. The effort bringing orm up-to-date with the > SQL is dwarfed by the work spent on that. One feature I like about ORM is that it doesn't force a specific object:table mapping. By that I mean my python objects can diverge from the database. For example, I can add computed attributes, extra methods, multiple objects that are different mappings of the same table - lots of things. Latter, Ross From orm-devel@mailman.tux4web.de Sat Dec 7 20:41:14 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sat, 07 Dec 2002 12:41:14 -0800 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) In-Reply-To: <15857.38793.483466.129648@lisa.tux4web.de> References: <15857.31732.683352.431293@lisa.tux4web.de> <3DF194C4.5070305@ericwalstad.com> <15857.38793.483466.129648@lisa.tux4web.de> Message-ID: <3DF25CEA.9070508@ericwalstad.com> Diedrich Vorberg wrote: >>Is FixedPoint now a requirement of orm? > > No it isn't. The import statement in orm.adapters.pgsql.datasource is > in a try: block and the except: will define a minimal class > FixedPoint which is a wraper around a Python string, really. > > If you only want the NUMERIC data as a string and simply use float() > on it you can skip installing FixedPoint and use it this way. You > might want to take a look, though, doesn't seem too bad. This sounds like a good solution, thanks! > Perhaps I should have integrated the simple string functionality in > CustomType as a default behaviour. I guess I'm not clear on when one would use CustomType. Is it meant to be extended by a class the user writes? Eric. From orm-devel@mailman.tux4web.de Sat Dec 7 20:43:51 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sat, 07 Dec 2002 12:43:51 -0800 Subject: [orm-devel] Re: ORM In-Reply-To: <5.1.0.14.0.20021207081304.0208b450@mail.mikewatkins.net> References: <15856.30532.3302.286222@lisa.tux4web.de> <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <5.1.0.14.0.20021207081304.0208b450@mail.mikewatkins.net> Message-ID: <3DF25D87.1090209@ericwalstad.com> Mike Watkins wrote: > I have a work around that uses pg_types table in Postgres, so you can > use psycopg. > > Attached... Cool. Nice work, Mike! Eric. From orm-devel@mailman.tux4web.de Sat Dec 7 20:47:46 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sat, 07 Dec 2002 12:47:46 -0800 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <1039279440.15330.132.camel@eeyore> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> <3DF18EA2.6040404@ericwalstad.com> <1039279440.15330.132.camel@eeyore> Message-ID: <3DF25E72.1080101@ericwalstad.com> Hi Uwe, Admin wrote: > Hi Eric, > > I appreciate what your saying and I agree that ORM shouldn't do full on > schema management. > > What I'm proposing is a way to minimize maintenance for us programmers. > > The way it stands at present we need to keep the ORM object and the SQL > table defs in line manually. Mikes code could be enhanced, if we found a > notation for relationships (see earlier post "Re: [orm-devel] Re: ORM"), > to return the class def to ORM based on the table schema. > > Uwe. Ah, I think I understand now. So you want to be able to make changes to the schema and then have orm automagically pick up those changes(?). It looks like Mike's "generate_orm.py" script is a good start. Eric. From orm-devel@mailman.tux4web.de Sat Dec 7 20:58:48 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Sat, 07 Dec 2002 12:58:48 -0800 Subject: [orm-devel] Automatic table modufication (was: orm) In-Reply-To: <20021207180310.GA8699@wallace.ece.rice.edu> References: <15856.29118.239734.580936@lisa.tux4web.de> <15856.30532.3302.286222@lisa.tux4web.de> <1039214154.10215.124.camel@eeyore> <20021206160650.GB30450@wallace.ece.rice.edu> <15857.22011.760583.23330@lisa.tux4web.de> <3DF18EA2.6040404@ericwalstad.com> <15857.38233.302588.875033@lisa.tux4web.de> <20021207180310.GA8699@wallace.ece.rice.edu> Message-ID: <3DF26108.8060206@ericwalstad.com> Ross J. Reedstrom wrote: > On Sat, Dec 07, 2002 at 07:29:45AM +0100, Diedrich Vorberg wrote: [snip my original misunderstanding of Automatic Table Mods] >>Personally I change around the tables a bit but that usually means >>changing the app, too. The effort bringing orm up-to-date with the >>SQL is dwarfed by the work spent on that. > > > One feature I like about ORM is that it doesn't force a specific > object:table mapping. By that I mean my python objects can diverge from > the database. For example, I can add computed attributes, extra methods, > multiple objects that are different mappings of the same table - lots > of things. I agree. Although I am using a couple of one2many and one many2many relationships in orm, there are some one to many database relationships that I don't want orm to handle. Specifically those where "many" is quite large and I want to have control of what (few) python objects are created in an effort to keep the app as speedy as possible. Eric. From orm-devel@mailman.tux4web.de Tue Dec 10 17:51:47 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Tue, 10 Dec 2002 18:51:47 +0100 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) In-Reply-To: <3DF25CEA.9070508@ericwalstad.com> References: <15857.31732.683352.431293@lisa.tux4web.de> <3DF194C4.5070305@ericwalstad.com> <15857.38793.483466.129648@lisa.tux4web.de> <3DF25CEA.9070508@ericwalstad.com> Message-ID: <15862.10675.830301.75687@lisa.tux4web.de> Hi Eric, >I guess I'm not clear on when one would use CustomType. Is it meant to >be extended by a class the user writes? the custom type is mainly called custom type because it will be used as a custom type cast within psycopg's type casting system. I've put some more explanations into the docstring for orm.adapters.pgsql.columns.customType (looks like Java, doesn't it :-) Anyway, besided that it can also be used to write custom orm datatype/column classes for custom types you registered with PostgreSQL. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Tue Dec 10 17:54:20 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Tue, 10 Dec 2002 18:54:20 +0100 Subject: [orm-devel] orm 0.8 Message-ID: <15862.10828.466203.983178@lisa.tux4web.de> Gentelmen - I have commited some minor docstring updates to the cvs repository. Could you please make sure your local work dirs are in sync and tell me if there are any major problems with this version of orm? If not so I'll put 0.8 up on freshmeat tomorrow night. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Tue Dec 10 19:29:39 2002 From: orm-devel@mailman.tux4web.de (Mike Watkins) Date: Tue, 10 Dec 2002 11:29:39 -0800 Subject: [orm-devel] The NUMERIC problem float-ing around (no more!) In-Reply-To: <3DF194C4.5070305@ericwalstad.com> References: <15857.31732.683352.431293@lisa.tux4web.de> <15857.31732.683352.431293@lisa.tux4web.de> Message-ID: <5.1.0.14.0.20021210112917.0209ad10@mail.mikewatkins.net> At 10:27 PM 12/6/2002 -0800, you wrote: >Good Morning! Wow, an all-nighter! You-da-man! :) >(My 3yr old daughter won't let me do all-nighter's any more) Neither will my 3 and 5 year old sons... although sometimes I end up being up, all... night. From orm-devel@mailman.tux4web.de Tue Dec 10 19:49:07 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Tue, 10 Dec 2002 11:49:07 -0800 Subject: [orm-devel] orm 0.8 In-Reply-To: <15862.10828.466203.983178@lisa.tux4web.de> References: <15862.10828.466203.983178@lisa.tux4web.de> Message-ID: <3DF64533.3040906@ericwalstad.com> I'll take a look at it right now. Eric. Diedrich Vorberg wrote: > Gentelmen - > > I have commited some minor docstring updates to the cvs repository. > Could you please make sure your local work dirs are in sync and tell > me if there are any major problems with this version of orm? If not so > I'll put 0.8 up on freshmeat tomorrow night. > > Diedrich From orm-devel@mailman.tux4web.de Tue Dec 10 19:53:24 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Tue, 10 Dec 2002 11:53:24 -0800 Subject: [orm-devel] orm 0.8 In-Reply-To: <15862.10828.466203.983178@lisa.tux4web.de> References: <15862.10828.466203.983178@lisa.tux4web.de> Message-ID: <3DF64634.40704@ericwalstad.com> Hi All, I had trouble with my ISP's email service the last few days. I believe that mail addressed to me was getting rejected. I tried browsing the list archives at: http://mailman.tux4web.de/mailman/listinfo/ and received an Apache 500 "Internal Server Error." So, I don't know if I'm missing any list posts addressed to me. Best, Eric. From orm-devel@mailman.tux4web.de Wed Dec 11 00:15:48 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Wed, 11 Dec 2002 01:15:48 +0100 Subject: [orm-devel] orm 0.8 In-Reply-To: <3DF64634.40704@ericwalstad.com> References: <15862.10828.466203.983178@lisa.tux4web.de> <3DF64634.40704@ericwalstad.com> Message-ID: <15862.33716.731008.843690@lisa.tux4web.de> Hi Eric, >http://mailman.tux4web.de/mailman/listinfo/ >and received an Apache 500 "Internal Server Error." So, I don't know if >I'm missing any list posts addressed to me. this seems to be a problem with Apach and cgi scripts on HPUX, I'm sorry about this. I restarted the server and I'll look into this right away. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---` From orm-devel@mailman.tux4web.de Wed Dec 11 00:58:17 2002 From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom) Date: Tue, 10 Dec 2002 18:58:17 -0600 Subject: [orm-devel] orm 0.8 In-Reply-To: <15862.10828.466203.983178@lisa.tux4web.de> References: <15862.10828.466203.983178@lisa.tux4web.de> Message-ID: <20021211005817.GB22680@wallace.ece.rice.edu> Hmm, my code quit working on the 6th, with this error: KeyError: _datasource_base__data You committed the change below to dbclass.py on that day. Any problem with reversing it? I backed it out myself, and my code works again. Especially since you didn't remember what you changed. ;-) Ross orm_cvs$ cvs diff -D 'Dec 6, 2002' dbclass.py Index: dbclass.py =================================================================== RCS file: /var/data/public_cvs/orm/dbclass.py,v retrieving revision 2.10 retrieving revision 2.11 diff -r2.10 -r2.11 30a31,33 > # Revision 2.11 2002/12/06 11:49:28 diedrich > # I know I changed something, I just don't remember what it was. > # 97c100 < __version__ = "$Revision: 2.10 $"[11:-2] --- > __version__ = "$Revision: 2.11 $"[11:-2] 344c347 < def _datasource_base__data(self): --- > def _datasource__data(self): 350c353 < def _datasource_base__setoid(self, oid): --- > def _datasource__setoid(self, oid): On Tue, Dec 10, 2002 at 06:54:20PM +0100, Diedrich Vorberg wrote: > Gentelmen - > > I have commited some minor docstring updates to the cvs repository. > Could you please make sure your local work dirs are in sync and tell > me if there are any major problems with this version of orm? If not so > I'll put 0.8 up on freshmeat tomorrow night. > > Diedrich > > -- > _..._ Diedrich Vorberg > .' '. > / _ _ \ http://www.tux4web.de > | (o)_(o) | info@tux4web.de > \( ) / .---. > //'._.'\ \ / \ Internet Dienstleistungen > // . \ \ \.@-@./ und 'Consulting'. > || . \ \ /`\_/`\ > |\ : / | // _ \\ Linux Rules! > \ `) ' (` /_ | \ )|_ > _)``".____,.'"` (_ /`\_`> <_/ \ > ) )'--'( ( \__/'---'\__/ > '---` `---` > > _______________________________________________ > orm-devel mailing list > orm-devel@mailman.tux4web.de > http://mailman.tux4web.de/mailman/listinfo/orm-devel -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Research Scientist phone: 713-348-6166 The Connexions Project http://cnx./rice.edu fax: 713-348-6182 Rice University MS-39 Houston, TX 77005 From orm-devel@mailman.tux4web.de Wed Dec 11 03:48:58 2002 From: orm-devel@mailman.tux4web.de (Eric Walstad) Date: Tue, 10 Dec 2002 19:48:58 -0800 Subject: [orm-devel] orm 0.8 In-Reply-To: <15862.33716.731008.843690@lisa.tux4web.de> References: <15862.10828.466203.983178@lisa.tux4web.de> <3DF64634.40704@ericwalstad.com> <15862.33716.731008.843690@lisa.tux4web.de> Message-ID: <3DF6B5AA.7020906@ericwalstad.com> Hi Diedrich, Thanks for restarting the server. I'm glad to see that I didn't miss any messages. FWIW, I didn't have any trouble with the latest CVS version, although I must admit I didn't test it very hard. If anything problems arise, I'll let you know. Thanks for your efforts! Eric. Diedrich Vorberg wrote: > Hi Eric, > > >>http://mailman.tux4web.de/mailman/listinfo/ >>and received an Apache 500 "Internal Server Error." So, I don't know if >>I'm missing any list posts addressed to me. > > > this seems to be a problem with Apach and cgi scripts on HPUX, I'm > sorry about this. I restarted the server and I'll look into this > right away. > > Diedrich From orm-devel@mailman.tux4web.de Wed Dec 11 15:28:03 2002 From: orm-devel@mailman.tux4web.de (Diedrich Vorberg) Date: Wed, 11 Dec 2002 16:28:03 +0100 Subject: [orm-devel] orm 0.8 In-Reply-To: <20021211005817.GB22680@wallace.ece.rice.edu> References: <15862.10828.466203.983178@lisa.tux4web.de> <20021211005817.GB22680@wallace.ece.rice.edu> Message-ID: <15863.22915.451473.961070@lisa.tux4web.de> Hi Ross, >Hmm, my code quit working on the 6th, with this error: > >KeyError: _datasource_base__data > >You committed the change below to dbclass.py on that day. Any problem >with reversing it? I backed it out myself, and my code works again. >Especially since you didn't remember what you changed. ;-) I did reverse it and checked it in, I think on the 6th. I just checked out orm completely and got the corrected dbclass.py. Hm... I don't know what heppened here. Anyway, you're correct renaming the methods back to their old names. Diedrich -- _..._ Diedrich Vorberg .' '. / _ _ \ http://www.tux4web.de | (o)_(o) | info@tux4web.de \( ) / .---. //'._.'\ \ / \ Internet Dienstleistungen // . \ \ \.@-@./ und 'Consulting'. || . \ \ /`\_/`\ |\ : / | // _ \\ Linux Rules! \ `) ' (` /_ | \ )|_ _)``".____,.'"` (_ /`\_`> <_/ \ ) )'--'( ( \__/'---'\__/ '---` `---`