Yikes.
Well, I did the port many months ago, and sent it to Chuck for integration into the WebWare core (there was one change to be made to the core, and the test suite had to be updated) but it looks like he still hasn't gotten around to it. I ended up not using my code, as our performance requirements turned out to be far greater than originally planned. Since I'm not using the code, I haven't been maintaining it, but I'll send it directly to you after this email (I'm CC'ing the list, which will probably bounce this if I add an attachment). There would probably be a lot of work to do to integrate it with changes made to MiddleKit in the last six months or so, and the fetch method requires looking through every table since there is no globally searchable OID in Postgres like there is in MySQL. Maybe you found a way around that problem. Anyway, like I said, I'm not using MiddleKit now, so my understanding of what I've written has probably faded, but I'll try and answer any questions you have. Greg Ernesto Revilla wrote: > Dear Greg, > > I think, I'm repeating all your work, as I didn't find a PostgreSQL-Adaptor for >MiddleKit. So we should decide, and simply post patches to whatever we need. > > As there are now 4 different python-DB-API 2.0 modules (PyGreSQL, PoPy, PsycoPg and >pyPgSQL), perhaps we can try to import all of these in any sequence and do some type >of abstraction, so it can use the first it finds. As I'm developing on a W2K machine, >the only compiled one I have is pyPgSQL. > > In the sense of database abstraction, I think it would be best to convert all data >to native Python types, to be absolute database independent. Although, this might >slow down the system. > > Where can I see the code of yout PgSQL? Is is free? Could it be integrated into >standard Webware distribution? > > Actually, I convert all the values to python-types. I put a hook in SQLObjectStore >which is called after fetchall(). > > I don't mind that ObjectRefs are of type long, but perhaps should be abstracted to >type ObjRefType or something like that. (I think in python 2.2 you can do something >like 'class ObjRef(long)' or 'class ObjRefType(types.LongType)'. > > Greetings, > Erny > > >>>Hi all, >>> >>>with the pyPgSQL some values are not returned as basic Python types. For Postgres >'bigint' I get a PgInt8 type. >>> >> >>Hi, >> >>Its been a very long time, but I was the one who wrote this code. Here is >>the discussion that I had with Chuck at the time: >> >> >> >> >> >> >> >>At 11:57 PM 7/26/2001 -0700, Greg Brauer wrote: >> >> >>-----Original Message----- >>From: Chuck Esterbrook <[EMAIL PROTECTED]> >>Date: Thu, 26 Jul 2001 23:33:40 -0400 >>Subject: Re: Think I've got it. >> >> > At 07:54 PM 7/26/2001 -0700, Gregory Brauer wrote: >> > >In otherwords, internally were always storing as Pg types. You had >> > >mentioned that a PgInt8 would be better than a long, memory wise, >> > >and had suggested using that as the internal storage mechanism. >> > >To be consistent then, a boolean would be the same. Do you think >> > I'm >> > >on the right track here? >> > >> > Basically and this obviously works. But then I'm wondering if this >> > will >> > affect the portability of MK code. Like if I switch my database from >> > Postgres to MySQL to something else, will this approach make it more >> > likely >> > for things to break? >> > >> > I'm leaning towards sticking with ordinary Python ints and longs for >> > this >> > reason. >> >>Ok, here's another factor. An ObjRef is hard coded in SQLObjectStore >>to be a long. So, I can't store references internally as an PGInt8, >>which is how they come out of the database. So now I'm faced with >>either >> >>a) overriding a major part of SQLObjectStore in PgSQLObjectStore, >> >>b) having ObjRefs be converted to Python native types, while Bools >>and Longs are Pg types, or >> >>c) converting all Pg Types to Python types across the board. >> >>What are your thoughts? >> >>I prefer (c) for bona fide Python values like bools and ints, but an obj ref >>that is a "long" really isn't about Python, it's about internal MK >>implementation. Looking at SQLObjectStore, it looks like the hard coding is >>the assertion in fetchObjRef(). We could change that to: >> >> assert type(value) in self.joinedObjRefTypes() >> >> def joinedObjRefTypes(self): >> return (types.LongType,) >> >>Then a subclass could override the method to return a tuple with more elements. >> >>There are also the funcs objRefJoin() and objRefSplit(), but since they use >>numerical operators, I don't think there should be interference with PgInt8. >> >>So in summary, my thoughts are, >> - convert all data (bool, int, long, float) to Pythonic data >> - let "joined" obj ref values be as efficient as they can be, which >>in this case would be a PgInt8 >> >> >>-Chuck >> >> >> >> >> >> >> >>And I'm pretty sure I did what was recommended here, so that is why a PgInt8 >>remains so... because it is most typically used to describe an obj ref. >> >>It's been 6 months since I looked at this code, so I appologize in advance >>if I'm wrong about something here. >> >>Greg >> >> > > _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
