From orm-devel@mailman.tux4web.de  Mon Feb 17 21:17:49 2003
From: orm-devel@mailman.tux4web.de (Michael Watkins)
Date: Mon, 17 Feb 2003 13:17:49 -0800
Subject: [orm-devel] Bug or feature in relationships.py
Message-ID: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>

Greetings all -

Warning, its been a little while since I last dug about in ORM so if I 
sound a little off base or deranged, please forgive me in advance. I may 
just need a gentle nudge here.

I had to dust off some web-forms code I wrote a while ago using ORM and 
just realized (I think) that there is a bug, or a misunderstood (on my 
part) feature in how the one2one relationship is implemented.

In reading my old code it looks like I set a "lookup" relationship between 
a parent object (say a document) and a status object (a small table of 
status items). When you change an existing parent object by reassigning a 
different status object, the change is made but the net effect is the row 
from the status table is deleted.

Line 172 of relationships.py in the set method of one2oneColumn contains:
         if self._data: self._data.delete()

This is a slightly different use case than what (I think) one2one 
envisions. The example Diedrich uses is a photograph to a person. I guess I 
can see deleting a photograph row if the persons photo is being replaced 
with another, so the delete that happens in lock step with the status_id 
attribute reassignment could make sense.

But it does not make sense in the scenario I present, where a Document 
might have a number of attributes which are simple lookups into other 
tables. To flesh this out more

Document has
	creation_date
	content
	status_id
	type_id
	subject_id

Status has
	id
	code
	description

Type has
	id
	code
	description

Subject has
	id
	code
	description
	

When a document has its status changed, the relationship between Document 
and a row in Status should change, but no rows in Status should be deleted.

Really the relationship between Document and Status is one2many i.e. one 
Status row relates to zero, one or many Document rows, but frequently you 
would not look at the relationship from that angle.

one2one functionally delivers all that is needed with the important 
exception of that delete happening on line 172. I guess I could just 
subclass it and modify its behaviour for myself but I imagine I'm not the 
only person with this need so here I am raising this.

Mike


From orm-devel@mailman.tux4web.de  Mon Feb 17 22:44:43 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Mon, 17 Feb 2003 23:44:43 +0100
Subject: [orm-devel] one2one relationship's behavior when reassigning (was: Bug or feature in relationships.py)
In-Reply-To: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
References: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
Message-ID: <15953.26075.336236.242629@lisa.tux4web.de>

Hi Mike!

>Line 172 of relationships.py in the set method of one2oneColumn contains:
>         if self._data: self._data.delete()

Mike's
> is a slightly different use case than what (I think) one2one 
>envisions. The example Diedrich uses is a photograph to a person. I guess I 
>can see deleting a photograph row if the persons photo is being replaced 
>with another, so the delete that happens in lock step with the status_id 
>attribute reassignment could make sense.

Orm thinks in objects. So a one2one relationship is a relationship
between objects. Deleting the parent also deletes the child as

   >>> del obj

also deletes obj's attributes... if obj is the only reference to 
them. 

>When a document has its status changed, the relationship between Document 
>and a row in Status should change, but no rows in Status should be deleted.

I can see that...

>one2one functionally delivers all that is needed with the important 
>exception of that delete happening on line 172. I guess I could just 
>subclass it and modify its behaviour for myself but I imagine I'm not the 
>only person with this need so here I am raising this.

and I too think subclassing is a good idea. It is a new kind of for orm
relation and should get a good name. From your eMail I guess 'lookup' 
suggests itself. At the company I used to work for these were 
referred to as 'domain tables", so perhaps 'domain' or 'domain_table'
would be a good idea. What do you think?

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 Feb 17 22:52:29 2003
From: orm-devel@mailman.tux4web.de (Ross J. Reedstrom)
Date: Mon, 17 Feb 2003 16:52:29 -0600
Subject: [orm-devel] Bug or feature in relationships.py
In-Reply-To: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
References: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
Message-ID: <20030217225228.GA8706@wallace.ece.rice.edu>

On Mon, Feb 17, 2003 at 01:17:49PM -0800, Michael Watkins wrote:
> Greetings all -
> 
> Warning, its been a little while since I last dug about in ORM so if I 
> sound a little off base or deranged, please forgive me in advance. I may 
> just need a gentle nudge here.
> 
> I had to dust off some web-forms code I wrote a while ago using ORM and 
> just realized (I think) that there is a bug, or a misunderstood (on my 
> part) feature in how the one2one relationship is implemented.
> 
> In reading my old code it looks like I set a "lookup" relationship between 
> a parent object (say a document) and a status object (a small table of 
> status items). When you change an existing parent object by reassigning a 
> different status object, the change is made but the net effect is the row 
> from the status table is deleted.

What you describe below is not a 1:1 relationship, but a n:1 (many to
one) - more than one row in the Document table shares the same Status
id, therefore it is not one to one. This is a common pattern, often
used exactly as you did, to map codes to larger descriptions. I'm not
sure this is currently supported in ORM (but it should be ;-) since you
can't really use one2many backwards, like you would in a generic SQL
schema description. 

Ross

From orm-devel@mailman.tux4web.de  Mon Feb 17 22:59:55 2003
From: orm-devel@mailman.tux4web.de (Michael Watkins)
Date: Mon, 17 Feb 2003 14:59:55 -0800
Subject: [orm-devel] Change request for dbclass
Message-ID: <5.1.0.14.0.20030217144830.039e1498@mail.mikewatkins.net>

I have a request for a minor change to dbclass.py to make it compatible 
with a Python based web application framework called Quixote ( 
http://www.mems-exchange.org/software/quixote/ check it out, it is very useful)

around line 200, place the following test:
         # MW next line is a patch to deal with Quixote.
         if name == "_p_oid" : return None

Quixote's forms handler has some useful widgets that make for quick and 
easy work with select lists. One aspect of the handler interrogates the 
object to see if it has an attribute _p_oid (this is a ZODB Zope Object DB 
attribute).

Better yet, lets make dbclass a little more generic so that it doesn't fail 
when code that isn't aware of ORM attempts to call an attribute that starts 
with '_' - that is the real source of the issue here - 
dbclass.__getattr__  needs a little clean up.

Look through the original code in the except block and let me know what you 
think.

     def __getattr__(self, name):
         """
         The __getattr__ method is overwriten to call each column's get
         method when an attribute is requested. Attributes that start
         with a _ are ignored.
         """
         # MW next line is a patch to deal with Quixote.
         if name == "_p_oid" : return None #self.__dict__['_oid']
         if name[0] == "_" : return self.__dict__[name]

         try:
             column = self._data[name]
         except KeyError:
             if self.columns.has_key(name):
                 return None
             else:
                 return self.__dict__[name]

         return column.get()


From orm-devel@mailman.tux4web.de  Mon Feb 17 23:02:07 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Tue, 18 Feb 2003 00:02:07 +0100
Subject: [orm-devel] Bug or feature in relationships.py
In-Reply-To: <20030217225228.GA8706@wallace.ece.rice.edu>
References: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
 <20030217225228.GA8706@wallace.ece.rice.edu>
Message-ID: <15953.27119.345660.947155@lisa.tux4web.de>

Hi Ross!

>What you describe below is not a 1:1 relationship, but a n:1 (many to
>one) - more than one row in the Document table shares the same Status
>id, therefore it is not one to one. This is a common pattern, often
>used exactly as you did, to map codes to larger descriptions. I'm not
>sure this is currently supported in ORM (but it should be ;-) since you
>can't really use one2many backwards, like you would in a generic SQL
>schema description. 

Of course!! You're right. I'll write it rightaway. One moment please...

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 Feb 17 23:05:21 2003
From: orm-devel@mailman.tux4web.de (Mike Watkins)
Date: Mon, 17 Feb 2003 15:05:21 -0800
Subject: [orm-devel] one2one relationship's behavior when
 reassigning (was: Bug or feature in relationships.py)
In-Reply-To: <15953.26075.336236.242629@lisa.tux4web.de>
References: <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
 <5.1.0.14.0.20030217130206.03a8d7d0@mail.mikewatkins.net>
Message-ID: <5.1.0.14.0.20030217150029.0399bdf8@mail.mikewatkins.net>

Diedrich, Ross -

Good comments from both. I agree the n:1 relationship should be in there - 
its a very common pattern.

In the short term I've called my new relationship class "lookup" and have 
lazily just duplicated the one2one code without the delete. I have not done 
much (yet) in the way of review of one2one to see if I've inherited other 
undesirable behaviour.

Ah, I see Diedrich volunteering to add a new class to the package !

Mike


At 11:44 PM 2/17/2003 +0100, you wrote:
>Hi Mike!
>
> >Line 172 of relationships.py in the set method of one2oneColumn contains:
> >         if self._data: self._data.delete()
>
>Mike's
> > is a slightly different use case than what (I think) one2one
> >envisions. The example Diedrich uses is a photograph to a person. I guess I
> >can see deleting a photograph row if the persons photo is being replaced
> >with another, so the delete that happens in lock step with the status_id
> >attribute reassignment could make sense.
>
>Orm thinks in objects. So a one2one relationship is a relationship
>between objects. Deleting the parent also deletes the child as
>
>    >>> del obj
>
>also deletes obj's attributes... if obj is the only reference to
>them.
>
> >When a document has its status changed, the relationship between Document
> >and a row in Status should change, but no rows in Status should be deleted.
>
>I can see that...
>
> >one2one functionally delivers all that is needed with the important
> >exception of that delete happening on line 172. I guess I could just
> >subclass it and modify its behaviour for myself but I imagine I'm not the
> >only person with this need so here I am raising this.
>
>and I too think subclassing is a good idea. It is a new kind of for orm
>relation and should get a good name. From your eMail I guess 'lookup'
>suggests itself. At the company I used to work for these were
>referred to as 'domain tables", so perhaps 'domain' or 'domain_table'
>would be a good idea. What do you think?
>
>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  Tue Feb 18 00:53:12 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Tue, 18 Feb 2003 01:53:12 +0100
Subject: [orm-devel] new many2one relationship in 0.9pre
Message-ID: <15953.33784.991503.421631@lisa.tux4web.de>

Good... morning?

I've added a new relationship/column pair called

  many2one

brought up my Mike, thought through and named by Ross and implemented
by myself this is a good example of teamwork ;-))

I moved some stuff from the one2one relationship into a common 
baseclass for 2one relationships which made more sense in terms of 
design than Mike's idea of just subclassing one2one, which would have 
worked, but this looks nicer.

If there are no major complains I'll raise orm some attention on 
freshmeat tomorrow with the 0.9 release.

There is 

   http://tux4web.de/orm/orm-0.9pre1.tar.gz

available now and I updated CVS repository, too.

One sidenote:
-------------
The changes have brought up an old problem I can see with orm:
caching. If you look at my test_many2one.py and run it you'll see that
orm performes one SELECT on the author table for each book although
most of them are redundant. I have intentionally not implemented a
caching mechanism of some sort, because I still want people to buy the
next version ;-) What I'm really saying is, caching, views and the oid
issue should wait untill after 1.0.

JOINs are another thing I'd like to take a look at. With the tables 
from my example you'd 

  SELECT book.id,book.title,author.id,author.name FROM book,author

Although this retrieves a lot of redundant data from the db it is 
actually better than orm's current solution: fewer (just one) SELECT 
request. I wonder how orm should do this. I have to think about this 
some more....

Any input is much appreciated!

Good night for me...
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 Feb 18 16:20:45 2003
From: orm-devel@mailman.tux4web.de (Mike Watkins)
Date: Tue, 18 Feb 2003 08:20:45 -0800
Subject: [orm-devel] new many2one relationship in 0.9pre
In-Reply-To: <15953.33784.991503.421631@lisa.tux4web.de>
Message-ID: <5.1.0.14.0.20030218082016.039e9390@mail.mikewatkins.net>

Very good Diedrich - I will do some testing of this a little later today.

Mike

At 01:53 AM 2/18/2003 +0100, you wrote:
>Good... morning?
>
>I've added a new relationship/column pair called
>
>   many2one


From orm-devel@mailman.tux4web.de  Thu Feb 20 17:12:19 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Thu, 20 Feb 2003 18:12:19 +0100
Subject: [orm-devel] ORM adapter for Firebird by Werner F. Bruhin
Message-ID: <15957.3187.223230.131771@lisa.tux4web.de>

Hi All,

Werner F. Bruhin wrote to me today about a new database adapter he's 
working on. I'll paste his original posting below and then reply to 
my own posting to avoid sending the source through the list. It will 
be available in the CVS shortly.

Diedrich

-------------

Dear Diedrich,

I would like to evaluate ORM (version 0.8) and SQLObjects (managed to 
get it working with Firebird) for a project,  but want to use it with 
Firebird.  So, I started putting a ORM-Firebird adapter together - 
looking at MySql and PostGre adapters you did and copied/pasted and 
changed a little.

Please keep in mind that I am new to Python and on top I am a hobby 
programer!

Firebird is different to PostGre and MySql in how it handles 
autoinc/sequence columns.  It has a generator and one can either use a 
trigger to generate the ID and would then have to do a query to get it 
(not sure that this can be done in a way which is 100% reliable), 
another method is to call a stored procedure which returns the ID to be 
used and insert that into the object before the actual insert is done - 
I prefer the later method.

My current problem is that I am not sure how to get to the connection 
and create a cursor and call the stored procedure.

If you have a moment could you glance at the attached datasource.py file 
and point me in the right direction on how I should deal with this in 
the insert function.

Another question, in my test script (see full script below) I have to insert

"from orm.adapters.firebird.columns import * "

to get the firebird columns, should that be automatically loaded by 
orm.datasources depending on what adapter type one is requesting??

Would appreciate any hints/help on this.

Best regards
Werner

From orm-devel@mailman.tux4web.de  Thu Feb 20 17:34:18 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Thu, 20 Feb 2003 18:34:18 +0100
Subject: [orm-devel] ORM adapter for Firebird by Werner F. Bruhin
In-Reply-To: <15957.3187.223230.131771@lisa.tux4web.de>
References: <15957.3187.223230.131771@lisa.tux4web.de>
Message-ID: <15957.4506.327955.394434@lisa.tux4web.de>

Hi Werner,

pleased to meet you!

>I would like to evaluate ORM (version 0.8) and SQLObjects (managed to 
>get it working with Firebird) for a project,  but want to use it with 
>Firebird.  So, I started putting a ORM-Firebird adapter together - 
>looking at MySql and PostGre adapters you did and copied/pasted and 
>changed a little.
That's great news! Actually there's not much more to do than that to 
create a new adapter.

>Firebird is different to PostGre and MySql in how it handles 
>autoinc/sequence columns.  It has a generator and one can either use a 
>trigger to generate the ID and would then have to do a query to get it 
>(not sure that this can be done in a way which is 100% reliable), 
>another method is to call a stored procedure which returns the ID to be 
>used and insert that into the object before the actual insert is done - 
>I prefer the later method.

>My current problem is that I am not sure how to get to the connection 
>and create a cursor and call the stored procedure.

Each datasource class has a _dbconn() method which returns a valid
DBAPI connection object. The default implementation (inherited from
datasource_base) just returns the _conn attribute of its object.

>Another question, in my test script (see full script below) I have to insert
>
>"from orm.adapters.firebird.columns import * "
>
>to get the firebird columns, should that be automatically loaded by 
>orm.datasources depending on what adapter type one is requesting??

Users are supposed to use lines like these:

  from orm.columns import *
  from orm.adapters.myadapter.columns import *

This way each adaper's custom datatype/column classes are available. 
Also, an adapter's column module could replace datatypes from orm's 
column module this way if that should be necessary.

>Would appreciate any hints/help on this.
Werner, your work is very much appreciated here and I'll be happy to 
answer any question you might have!

I'll put the files you sent into the CVS repository now, so they
should be available shortly. I'll put comments in when I think it
might be helpful.

Also, if you are interested, I can create an account on
c200.tux4web.de for you, so you can check in your changes and keep a
$Log$ using CVS. Do you have ssh and cvs installed?

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 Feb 20 21:07:24 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Thu, 20 Feb 2003 22:07:24 +0100
Subject: [orm-devel] ORM adapter for Firebird by Werner F. Bruhin
In-Reply-To: <15957.4506.327955.394434@lisa.tux4web.de>
References: <15957.3187.223230.131771@lisa.tux4web.de> <15957.4506.327955.394434@lisa.tux4web.de>
Message-ID: <3E55438C.2010502@free.fr>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Diedrich,<br>
<br>
Thanks for the quick reply.<br>
<br>
Note that the code I sent you is NOT functional yet, need to get the
call to the stored procedure working (at a minimum!) and work over the
documentation strings.<br>
<br>
Will try work on it over the next few days and you can count on it that
I will be in touch.<br>
<br>
See you<br>
Werner<br>
<br>
Diedrich Vorberg wrote:<br>
<blockquote type="cite"
 cite="mid15957.4506.327955.394434@lisa.tux4web.de">
  <pre wrap="">Hi Werner,

pleased to meet you!

  </pre>
  <blockquote type="cite">
    <pre wrap="">I would like to evaluate ORM (version 0.8) and SQLObjects (managed to 
get it working with Firebird) for a project,  but want to use it with 
Firebird.  So, I started putting a ORM-Firebird adapter together - 
looking at MySql and PostGre adapters you did and copied/pasted and 
changed a little.
    </pre>
  </blockquote>
  <pre wrap=""><!---->That's great news! Actually there's not much more to do than that to 
create a new adapter.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Firebird is different to PostGre and MySql in how it handles 
autoinc/sequence columns.  It has a generator and one can either use a 
trigger to generate the ID and would then have to do a query to get it 
(not sure that this can be done in a way which is 100% reliable), 
another method is to call a stored procedure which returns the ID to be 
used and insert that into the object before the actual insert is done - 
I prefer the later method.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">My current problem is that I am not sure how to get to the connection 
and create a cursor and call the stored procedure.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Each datasource class has a _dbconn() method which returns a valid
DBAPI connection object. The default implementation (inherited from
datasource_base) just returns the _conn attribute of its object.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Another question, in my test script (see full script below) I have to insert

"from orm.adapters.firebird.columns import * "

to get the firebird columns, should that be automatically loaded by 
orm.datasources depending on what adapter type one is requesting??
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Users are supposed to use lines like these:

  from orm.columns import *
  from orm.adapters.myadapter.columns import *

This way each adaper's custom datatype/column classes are available. 
Also, an adapter's column module could replace datatypes from orm's 
column module this way if that should be necessary.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Would appreciate any hints/help on this.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Werner, your work is very much appreciated here and I'll be happy to 
answer any question you might have!

I'll put the files you sent into the CVS repository now, so they
should be available shortly. I'll put comments in when I think it
might be helpful.

Also, if you are interested, I can create an account on
c200.tux4web.de for you, so you can check in your changes and keep a
$Log$ using CVS. Do you have ssh and cvs installed?

Diedrich

  </pre>
</blockquote>
</body>
</html>



From orm-devel@mailman.tux4web.de  Sat Feb 22 21:40:18 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Sat, 22 Feb 2003 22:40:18 +0100
Subject: [orm-devel] ORM adapter for Firebird by Werner F. Bruhin
In-Reply-To: <15957.4506.327955.394434@lisa.tux4web.de>
References: <15957.3187.223230.131771@lisa.tux4web.de> <15957.4506.327955.394434@lisa.tux4web.de>
Message-ID: <3E57EE42.5050206@free.fr>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Diedrich,<br>
<br>
I finally got FB 1.5 beta 2 to work today, this is one of the reasons I
haven't got back to you before.<br>
<br>
1.5 provides a nicer way of implementing the Generator stuff (can exec
a statement within a stored procedure - although can not get it to work
yet).<br>
<br>
Your last mail was all I needed to get the db connection going.<br>
<br>
Hope to have some update early next week - which should handle at least
the basics.<br>
<br>
I do have CVS (Tortoise) which has SSH built in, so if it makes things
easier for everyone set up an account, otherwise I just keep sending
you the two files.<br>
<br>
Best regards<br>
Werner<br>
<br>
Diedrich Vorberg wrote:<br>
<blockquote type="cite"
 cite="mid15957.4506.327955.394434@lisa.tux4web.de">
  <pre wrap="">Hi Werner,

pleased to meet you!

  </pre>
  <blockquote type="cite">
    <pre wrap="">I would like to evaluate ORM (version 0.8) and SQLObjects (managed to 
get it working with Firebird) for a project,  but want to use it with 
Firebird.  So, I started putting a ORM-Firebird adapter together - 
looking at MySql and PostGre adapters you did and copied/pasted and 
changed a little.
    </pre>
  </blockquote>
  <pre wrap=""><!---->That's great news! Actually there's not much more to do than that to 
create a new adapter.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Firebird is different to PostGre and MySql in how it handles 
autoinc/sequence columns.  It has a generator and one can either use a 
trigger to generate the ID and would then have to do a query to get it 
(not sure that this can be done in a way which is 100% reliable), 
another method is to call a stored procedure which returns the ID to be 
used and insert that into the object before the actual insert is done - 
I prefer the later method.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">My current problem is that I am not sure how to get to the connection 
and create a cursor and call the stored procedure.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Each datasource class has a _dbconn() method which returns a valid
DBAPI connection object. The default implementation (inherited from
datasource_base) just returns the _conn attribute of its object.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Another question, in my test script (see full script below) I have to insert

"from orm.adapters.firebird.columns import * "

to get the firebird columns, should that be automatically loaded by 
orm.datasources depending on what adapter type one is requesting??
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Users are supposed to use lines like these:

  from orm.columns import *
  from orm.adapters.myadapter.columns import *

This way each adaper's custom datatype/column classes are available. 
Also, an adapter's column module could replace datatypes from orm's 
column module this way if that should be necessary.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Would appreciate any hints/help on this.
    </pre>
  </blockquote>
  <pre wrap=""><!---->Werner, your work is very much appreciated here and I'll be happy to 
answer any question you might have!

I'll put the files you sent into the CVS repository now, so they
should be available shortly. I'll put comments in when I think it
might be helpful.

Also, if you are interested, I can create an account on
c200.tux4web.de for you, so you can check in your changes and keep a
$Log$ using CVS. Do you have ssh and cvs installed?

Diedrich

  </pre>
</blockquote>
</body>
</html>



From orm-devel@mailman.tux4web.de  Thu Feb 27 17:20:38 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Thu, 27 Feb 2003 18:20:38 +0100
Subject: [orm-devel] Firebird adapter
In-Reply-To: <3E57EE42.5050206@free.fr>
References: <15957.3187.223230.131771@lisa.tux4web.de> <15957.4506.327955.394434@lisa.tux4web.de> <3E57EE42.5050206@free.fr>
Message-ID: <3E5E48E6.90707@free.fr>

Firebird has released Beta 3, hoped to get some support in that beta to
allow the implementation of the ORM adapter for Firebird to have just
one stored procedure.  Unfortunately it did not make it and the Firebird
developer would/could not give a date nor which beta would contain that
patch so I decided to go ahead and implement it with what is there now 
(an advantage is that it supports FB 1.02 and might even work for 
Interbase, so that I don't know for sure).

This means that per generated column (autoinc in Firebird) we will need
a Generator and one stored procedure.  To facilitate this I created an
"fbgen.py" which generates the Firebird class definitions and the SQL to
create the generator and the stored procedure, one just has to copy/past
this into a SQL script exec like ibexpert to create things in the db.

Here some links were you can get some stuff you will probably need/want.

*Firebird DB* (really any release, at least for the moment):
http://www.firebirdsql.org/

If you get beta 3 you have to do some manual install steps (at least on
Windows):
- extract ZIP file to e.g. c:\program files\firebird
- go to c:\program files\firebird\bin
- instreg install "c:\program files\firebird" -z
- instsvc install "c:\program files\firebird" -auto -g

*Python Extension package for Firebird*
http://kinterbasdb.sourceforge.net/

*Firebird manager* (stop/start if installed as service, support of
multiple versions of FB)
http://www.achim-kalwa.de/dl/fbmgr-setup.exe

*DB managing/adminstration tool
*I use IBExpert personal edition (free), tried out full version which
includes additional tools such as Grant Manager, User Manager, SQL
debugger and DB design tool which can reverse engineer DB (I did a
Paradox DB to FB, without any problems - requires a plug in).

http://www.hksoftware.net/download/ibep_2.5.0.22_full.exe  (link to
personal version which is free)

Other options are:
www.ibaccess.org
http://ems-hitech.com/ibmanager/

Hope I did not forget anything - obviously you will need latest version
of ORM (see next posting).

See you
Werner





From orm-devel@mailman.tux4web.de  Thu Feb 27 17:25:52 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Thu, 27 Feb 2003 18:25:52 +0100
Subject: [orm-devel] CVS commit questions
In-Reply-To: <3E57EE42.5050206@free.fr>
References: <15957.3187.223230.131771@lisa.tux4web.de> <15957.4506.327955.394434@lisa.tux4web.de> <3E57EE42.5050206@free.fr>
Message-ID: <3E5E4A20.30609@free.fr>

Diedrich,

Especially as I never used CVS in a shared environment (I am using it 
for my stuff on my machine - but only for a few month) would just like 
to check before I do the commit with the latest updates that I will do 
the correct steps.

- Do a CVS/Update on ORM directory
- Resolve any conflict(s)
- Do a CVS/Add on any new files
- Do a CVS/Commit on files I changed/added

FYI - following are files I worked on:
- orm.datasource - added two lines to enable Firebird adapter
- firebird.datasource and column - updated to handle stored procedure call
- contrib.fbgen* - new file to generate class and SQL code
- example.test_firebird - updated to handle commit for insert and added 
and update (however on this I have a problem).

Please let me know if this is fine.

After I committed to CVS please feel free to comment on the code, I am 
sure that one can improve/simplify things if one has a better 
understanding of things.  I also do NOT mind comments on code style, as 
I am doing quit a lot of looking at other peoples code to try to learn 
things I find myself getting quit confused on the different coding styles.

Best regards
Werner





From orm-devel@mailman.tux4web.de  Thu Feb 27 17:29:01 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Thu, 27 Feb 2003 18:29:01 +0100
Subject: [orm-devel] Firebird adapter - problem with update
Message-ID: <3E5E4ADD.9020308@free.fr>

Trying to do an update I get a token unknown on the following:

ds.update(w, 'winename', 'some')

This works:

ds.update(w, 'winename', '\'some\'')

I think ORM should by default retain the quotes, or am I missing something?

See you
Werner




From orm-devel@mailman.tux4web.de  Thu Feb 27 20:32:01 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Thu, 27 Feb 2003 21:32:01 +0100
Subject: [orm-devel] CVS commit questions
In-Reply-To: <3E5E4A20.30609@free.fr>
References: <15957.3187.223230.131771@lisa.tux4web.de>
 <15957.4506.327955.394434@lisa.tux4web.de>
 <3E57EE42.5050206@free.fr>
 <3E5E4A20.30609@free.fr>
Message-ID: <15966.30145.693707.173803@lisa.tux4web.de>

Hi Werner,

>Please let me know if this is fine.
Yes, that sounds great, just go ahead and! 

>After I committed to CVS please feel free to comment on the code, I am 
>sure that one can improve/simplify things if one has a better 
>understanding of things.  I also do NOT mind comments on code style, as 
>I am doing quit a lot of looking at other peoples code to try to learn 
>things I find myself getting quit confused on the different coding styles.
Alright, can do! 

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 Feb 28 09:58:07 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Fri, 28 Feb 2003 10:58:07 +0100
Subject: [orm-devel] Firebird adapter
In-Reply-To: <3E5E48E6.90707@free.fr>
References: <15957.3187.223230.131771@lisa.tux4web.de> <15957.4506.327955.394434@lisa.tux4web.de> <3E57EE42.5050206@free.fr> <3E5E48E6.90707@free.fr>
Message-ID: <3E5F32AF.8010002@free.fr>

Forgot a step if you use FB 1.5 beta.

You need to copy fbclient.dll and gds32.dll from firebird/bin to 
windows/system32 directory.

Sorry about this
Werner

Werner F. Bruhin wrote:

> Firebird has released Beta 3, hoped to get some support in that beta to
> allow the implementation of the ORM adapter for Firebird to have just
> one stored procedure.  Unfortunately it did not make it and the Firebird
> developer would/could not give a date nor which beta would contain that
> patch so I decided to go ahead and implement it with what is there now 
> (an advantage is that it supports FB 1.02 and might even work for 
> Interbase, so that I don't know for sure).
>
> This means that per generated column (autoinc in Firebird) we will need
> a Generator and one stored procedure.  To facilitate this I created an
> "fbgen.py" which generates the Firebird class definitions and the SQL to
> create the generator and the stored procedure, one just has to copy/past
> this into a SQL script exec like ibexpert to create things in the db.
>
> Here some links were you can get some stuff you will probably need/want.
>
> *Firebird DB* (really any release, at least for the moment):
> http://www.firebirdsql.org/
>
> If you get beta 3 you have to do some manual install steps (at least on
> Windows):
> - extract ZIP file to e.g. c:\program files\firebird
> - go to c:\program files\firebird\bin
> - instreg install "c:\program files\firebird" -z
> - instsvc install "c:\program files\firebird" -auto -g
>
> *Python Extension package for Firebird*
> http://kinterbasdb.sourceforge.net/
>
> *Firebird manager* (stop/start if installed as service, support of
> multiple versions of FB)
> http://www.achim-kalwa.de/dl/fbmgr-setup.exe
>
> *DB managing/adminstration tool
> *I use IBExpert personal edition (free), tried out full version which
> includes additional tools such as Grant Manager, User Manager, SQL
> debugger and DB design tool which can reverse engineer DB (I did a
> Paradox DB to FB, without any problems - requires a plug in).
>
> http://www.hksoftware.net/download/ibep_2.5.0.22_full.exe  (link to
> personal version which is free)
>
> Other options are:
> www.ibaccess.org
> http://ems-hitech.com/ibmanager/
>
> Hope I did not forget anything - obviously you will need latest version
> of ORM (see next posting).
>
> See you
> Werner
>
>
>
>
> _______________________________________________
> orm-devel mailing list
> orm-devel@mailman.tux4web.de
> http://mailman.tux4web.de/mailman/listinfo/orm-devel
>
>




From orm-devel@mailman.tux4web.de  Fri Feb 28 10:25:44 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Fri, 28 Feb 2003 11:25:44 +0100
Subject: [orm-devel] Firebird adapter - new version and a question
Message-ID: <3E5F3928.806@free.fr>

Diedrich,

New version is up on CVS.

Should I not change the "gen" column to serial, obviously with special 
handling in the FB adapter.  The idea would be that it would be very 
nice if the class definitions of ORM stay DB independent, so that one 
can write stuff and switch from one db to another WITHOUT having to make 
any changes (at least to the ORM related stuff).

What do you think?


See you
Werner




From orm-devel@mailman.tux4web.de  Fri Feb 28 10:31:01 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Fri, 28 Feb 2003 11:31:01 +0100
Subject: [orm-devel] [Fwd: [wxPython-users] Data-aware Grid]
Message-ID: <3E5F3A65.2060502@free.fr>

Diedrich,

Are you aware of this thread on wxPython list?

I believe they are using ORM for this, so might be useful to track what 
they are doing and if they need any special support.

BTW - this is how I found out about ORM in the first place.

See you
Werner

-------- Original Message --------
Subject: [wxPython-users] Data-aware Grid
Date: 13 Feb 2003 08:00:34 -0500
From: Nathan R. Yergler <nathan@yergler.net>
Reply-To: wxPython-users@lists.wxwindows.org
To: wxPython-users@lists.wxwindows.org



I'm working on a project that requires quite a bit of data to be
displayed in an editable grid.  For this reason, I have begun work on a
data-aware grid.  The approach I'm taking is to create a subclass of
wxPyGridTableBase which handles the interraction between the database
and the grid.  My question for the list is what is the most useful way
to implement the data connection?  I'm currently considering the
following options:

1) DB-API only: use Python's db-api defined classes and accept (may) a
cursor and a column list in the table constructor.  This has the
advantage that no additional modules are needed (except the specific
db-api module, of course) and it supports a wide variety of databases. 
The disadvantage is that it will probably be the most "bare bones"
implementation: using the resulting class will require intimate
knowledge of the database, etc.

2) SQLObject (http://colorstudy.com/software/SQLObject/): 
3) ORM (http://www.tux4web.de/orm/):
   Both are ways to abstractly represent a table or dataset.  Both have
subtle things that preventing me from fully loving them, but both have a
pretty good feature set.  I guess I tend to prefer SQLObject because it
more fully masks the database stuff, but I could be swayed.

Are there other connection models I'm not considering?  Are there other
ideas I should take into account?  Any feedback will be appreciated.

Thanks,

Nathan R. Yergler





---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org







From orm-devel@mailman.tux4web.de  Fri Feb 28 11:22:13 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Fri, 28 Feb 2003 12:22:13 +0100
Subject: [orm-devel] Firebird adapter - new version and a question
In-Reply-To: <3E5F3928.806@free.fr>
References: <3E5F3928.806@free.fr>
Message-ID: <15967.18021.142234.903141@lisa.tux4web.de>

Hi Werner,

>New version is up on CVS.
Thank you very much! It looks great, actually I don't think it could 
have been any more efficient than that. 

>Should I not change the "gen" column to serial, obviously with special 
>handling in the FB adapter.  The idea would be that it would be very 
>nice if the class definitions of ORM stay DB independent, so that one 
>can write stuff and switch from one db to another WITHOUT having to make 
>any changes (at least to the ORM related stuff).
>
>What do you think?

No, I think the name is fine.

ORM's basic idea has been to wrap the database backends in a 'opaque'
way, i.e. you're sopposed to see then shining through. The programmer
is supposed to know (and appreciate) his basic SQL. A "plug, play and
plug another" design like with real object relational layer is not
what I had in mind.

In my experiance these products only claim backend independence but 
you'll have to test and debug with any backend you're going to use 
anyway. Also you'll have to introduce tons of if {} statements to 
compansate for bugs you didn't make. As a result most applications 
stick with one RDBMS.

With orm you'll have to provide backend independance yourself. If I'd 
want my program to work with say psql and FB I'd:

   if pgsql:
     from orm.adapter.pgsql.datasource import datasource
     from orm.adapter.pgsql.columns import *
   elif FB:
     from orm.adapter.firebird.datasource import datasource
     from orm.adapter.firebird.columns import *

     serial = gen

It might be a good idea to provide a meta-adapter that takes care of 
this kind of think and provides a number of unified SQL type names 
and corresponding column types.

Anyway I think that each individual adapter should stay as close to 
its RDBMS as it can.

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 Feb 28 12:54:53 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Fri, 28 Feb 2003 13:54:53 +0100
Subject: [orm-devel] select problem
Message-ID: <3E5F5C1D.3020409@free.fr>

I am having a problem trying to do a select:

w2 = ds.selectByPrimaryKey(test, 45)

debug output is: SELECT test.id,test.winename FROM test WHERE id=45

getting this error:

  File "test_firebird.py", line 61, in ?
    w2 = ds.selectByPrimaryKey(test, 45)
  File "C:\Python22\lib\site-packages\orm\datasource.py", line 330, in 
selectByPrimaryKey
    raise IllegalPrimaryKey("%s in %s" % (fmt, dbclass.__name__))

I now that 45 exists and is a valid key in the DB, but ORM does not like it.

The class definition is the one from test_firebird.py.

Any hints/help would be appreciated.

See you
Werner






From orm-devel@mailman.tux4web.de  Fri Feb 28 13:22:09 2003
From: orm-devel@mailman.tux4web.de (Diedrich Vorberg)
Date: Fri, 28 Feb 2003 14:22:09 +0100
Subject: [orm-devel] select problem
In-Reply-To: <3E5F5C1D.3020409@free.fr>
References: <3E5F5C1D.3020409@free.fr>
Message-ID: <15967.25217.226664.238413@lisa.tux4web.de>

Hi Werner,

>debug output is: SELECT test.id,test.winename FROM test WHERE id=45
>Any hints/help would be appreciated.

Try running the query on a plain cursor to see if it returns the 
dataset you'd expect. Use the selectone() method of the cursor and 
check the tuple that's returned. That's exactly what orm does just a 
couple more functioncalls involved..:-)

I'll set up firebird on Linux today and try it myself. Untill than I 
can't say much more.

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 Feb 28 13:52:34 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Fri, 28 Feb 2003 14:52:34 +0100
Subject: [orm-devel] select problem
In-Reply-To: <15967.25217.226664.238413@lisa.tux4web.de>
References: <3E5F5C1D.3020409@free.fr> <15967.25217.226664.238413@lisa.tux4web.de>
Message-ID: <3E5F69A2.9070508@free.fr>

Hi Diedrich,

I checked if I get the correct result using kinterbasdb directly with 
the following little script.
import kinterbasdb

con = 
kinterbasdb.connect(dsn="c:\\dev\mywinecb\\data\\mywinecb.gdb",user="sysdba",password="masterkey",charset="ISO8859_1")

cur = con.cursor()

cur.execute("SELECT test.id,test.winename FROM test WHERE id=45")
#cur.execute("SELECT* FROM test")
print cur.fetchall()

The select with the where clause returns the right column.

Debugging ORM I do not see when the fetchxxx (one or all is called).

Will go and make myself a tea, maybe that will clear up my vision!

Have fun with Firebird on Linux.

See you
Werner

Diedrich Vorberg wrote:

>Hi Werner,
>
>  
>
>>debug output is: SELECT test.id,test.winename FROM test WHERE id=45
>>Any hints/help would be appreciated.
>>    
>>
>
>Try running the query on a plain cursor to see if it returns the 
>dataset you'd expect. Use the selectone() method of the cursor and 
>check the tuple that's returned. That's exactly what orm does just a 
>couple more functioncalls involved..:-)
>
>I'll set up firebird on Linux today and try it myself. Untill than I 
>can't say much more.
>
>Diedrich
>
>  
>



From orm-devel@mailman.tux4web.de  Fri Feb 28 17:38:59 2003
From: orm-devel@mailman.tux4web.de (Eric Walstad)
Date: Fri, 28 Feb 2003 09:38:59 -0800
Subject: [orm-devel] [Fwd: [wxPython-users] Data-aware Grid]
In-Reply-To: <3E5F3A65.2060502@free.fr>
References: <3E5F3A65.2060502@free.fr>
Message-ID: <3E5F9EB3.5050506@ericwalstad.com>

Hi All,

I was hoping Nathan would go with ORM but, if I understand where they 
are going with it, they are going to build another abstraction layer 
that will allow ORM or others to provide the data to the grid.
I wanted to work on this, too, but I'm full-up with other work right now.

BTW, thanks for your efforts on the FB code, Werner!

Eric.

Werner F. Bruhin wrote:
> Diedrich,
> 
> Are you aware of this thread on wxPython list?
> 
> I believe they are using ORM for this, so might be useful to track what 
> they are doing and if they need any special support.
> 
> BTW - this is how I found out about ORM in the first place.
> 
> See you
> Werner
> 
> -------- Original Message --------
> Subject: [wxPython-users] Data-aware Grid
> Date: 13 Feb 2003 08:00:34 -0500
> From: Nathan R. Yergler <nathan@yergler.net>
> Reply-To: wxPython-users@lists.wxwindows.org
> To: wxPython-users@lists.wxwindows.org
> 
> 
> 
> I'm working on a project that requires quite a bit of data to be
> displayed in an editable grid.  [... snip]


From orm-devel@mailman.tux4web.de  Fri Feb 28 17:49:59 2003
From: orm-devel@mailman.tux4web.de (Werner F. Bruhin)
Date: Fri, 28 Feb 2003 18:49:59 +0100
Subject: [orm-devel] [Fwd: [wxPython-users] Data-aware Grid]
In-Reply-To: <3E5F9EB3.5050506@ericwalstad.com>
References: <3E5F3A65.2060502@free.fr> <3E5F9EB3.5050506@ericwalstad.com>
Message-ID: <3E5FA147.8020302@free.fr>

Eric,

No prob, however still ways to go before it is really working.

See you
Werner

Eric Walstad wrote:

> Hi All,
>
> I was hoping Nathan would go with ORM but, if I understand where they 
> are going with it, they are going to build another abstraction layer 
> that will allow ORM or others to provide the data to the grid.
> I wanted to work on this, too, but I'm full-up with other work right now.
>
> BTW, thanks for your efforts on the FB code, Werner!
>
> Eric.
>
> Werner F. Bruhin wrote:
>
>> Diedrich,
>>
>> Are you aware of this thread on wxPython list?
>>
>> I believe they are using ORM for this, so might be useful to track 
>> what they are doing and if they need any special support.
>>
>> BTW - this is how I found out about ORM in the first place.
>>
>> See you
>> Werner
>>
>> -------- Original Message --------
>> Subject: [wxPython-users] Data-aware Grid
>> Date: 13 Feb 2003 08:00:34 -0500
>> From: Nathan R. Yergler <nathan@yergler.net>
>> Reply-To: wxPython-users@lists.wxwindows.org
>> To: wxPython-users@lists.wxwindows.org
>>
>>
>>
>> I'm working on a project that requires quite a bit of data to be
>> displayed in an editable grid.  [... snip]
>
>
> _______________________________________________
> orm-devel mailing list
> orm-devel@mailman.tux4web.de
> http://mailman.tux4web.de/mailman/listinfo/orm-devel
>
>



From mw at mikewatkins.net  Thu Feb 27 17:36:57 2003
From: mw at mikewatkins.net (Michael Watkins)
Date: Thu Feb 27 17:36:59 2003
Subject: [orm-devel] The mailinglists are back!
In-Reply-To: <16465.51414.85991.721230@lisa.local.>
References: <16465.51414.85991.721230@lisa.local.>
Message-ID: <1079120609.2847.7.camel@frog.mikewatkins.net>

Very good to hear from you again Diedrich, looking forward to checking
out CVS.

--
Mike Watkins
mw@mikewatkins.net


"What George Washington did for us was to throw out the British, so
that we wouldn't have a fat, insensitive government running our
country. Nice try anyway, George."
		-- D.J. on KSFO/KYA

From werner.bruhin at free.fr  Thu Feb 27 17:43:29 2003
From: werner.bruhin at free.fr (Werner F. Bruhin)
Date: Thu Feb 27 17:43:30 2003
Subject: [orm-devel] The mailinglists are back!
In-Reply-To: <16465.51414.85991.721230@lisa.local.>
References: <16465.51414.85991.721230@lisa.local.>
Message-ID: <40557879.7070904@free.fr>

Diedrich Vorberg wrote:

>Hello everybody,
>
>after I have finally reclaimed my server with the orm mailinglist
>archives and the CVS repository(!) on it, I've been able to copy the
>lists to a new server and commit the (rather extensive) changes I made
>during the past view months.
>
>There's a new layout for the example and unit test direcory and view
>interface changes (most noteable the join class). I've started
>implementing some ideas for user interface programming with orm, which
>I've been using for a number of projects now, but I didn't clean up
>the code and write documentation and examples, yet. Check out the CVS
>version if you're interested!
>
>Diedrich
>
>  
>
Hi Diedrich,

Good to hear from you.

Won't have time in the near future to look at it, hopefully sometimes 
this summer.

See you
Werner