From: Graham H. <gr...@ly...> - 2001-04-09 23:04:09
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chuck Esterbrook <ec...@mi...> writes: > >I've been looking through MiddleKit in the 0.5.1rc2 release > >(incidentally, very easy to follow code; thank you!), and have a list > >of things that would need to be changed to have a PostgreSQL backend, > >something I would need to be able to use MK. I'm willing to implement > >this stuff, incidentally. > > That would be great. Postgres support for MK comes up quite a bit. I can imagine. > >o You use /* a lot. /*, despite being recognized by Postgres and > > MySQL both, isn't really proper SQL syntax: real SQL comments match > > the regexp `--.*$'. I'm not going to change this, as Pg supports > > the C style block comments. > > The SQL classes are meant more to be "commonly accepted" instead of > "ANSI". Inevitably, I find "what works for all products" is a little > more important than "what the standards committee said". Quite. Postgres distinguishes itself by having an ANSI compatibility section for each of the major commands in its manual, but that just means it's incompatible with everything *else*... Oracle's date type comes to mind here. > Pg, MySQL and MSSQL all support /* */, so we'll just go with that > for now. *nod* > >o Postgres has different syntax for drop database (no if exists > > clause, mostly) and changing to a new database, as well as IDs and a > > couple other minor things. Not a big deal. > > Also connecting to a database. You have to specify this up front with > Pg whereas other DBs will let you send SQL to connect (which is the > idea that SQLObjectStore currently embraces). Hmm... I know that I use \c when I'm sending SQL directly to psql, but I'd forgotten that it's not quite the same thing when using a socket connection. I'll have to think about that for a bit. On the other hand the \c trick will probably work for Generate.py. > >o You use enum (...), which isn't in ANSI; I assume this is a MySQL > > thing, as the normal way to do it in ANSI is `varchar (<max enum > > length>) check (<column_name> in (...))' which requires some sort of > > referential integrity checking. > > Yeah, I wasn't sure how to do enum's in ANSI, so I went with > this. Unfortunately, I don't have my "SQL in a Nutshell" book with me > as I'm travelling. That book covers SQL including real life > differences in MySQL, Pg, Oracle and Microsoft. If I dealt with lots of databases it sounds like it would be a real asset. As it is I've managed to avoid dealing with most of those. <int4 references Video (videoId)> > MySQL doesn't support explicit references which is how I arrived at > this code. In practice, pretty much every specific DB subclass will > need to provide it's own ObjRefAttr.sqlType(). *nod* > BTW It's 64-bits because 32 are the class identifier and 32 are the > object identifier within that class. Aah. Hmm. That won't reference check directly; thanks for the warning, tho. I'll have to look into how to get that to work right. > I'll check if "int8 unsigned" or something similar is supported by > both ANSI and the popular databases. If so, I'd have no problem > switching to that. Unsigned ints are not supported in Postgres, but int8 is in the manual (although it says it requires compiler support for it, so maybe not on all platforms). > >o Generate.py would of course need to be hacked slightly, but only > > slightly. > > Yeah, I sectioned off the "mysql" stuff into methods that can be > gutted and worked off a config file. Cool. <SQLObjectStore and retrieveLastInsertID> > We'll have to refactor some of the methods and behavior of > SQLObjectStore to support Pg. Even the simple lack of "if exists" and > "use" in Pg creates this need. *nod* > I wouldn't worry about 0.5.1 compatibility. I would worry about the > mainline CVS. Well, the reason I can get the time to write the Postgres stuff is because I need this for work (of course...). Do you lot want papers like the FSF do? > >o I'm pretty sure I know how to retrofit transaction support onto the > > object store, which speaks well for the design; I can even get > > revertChanges in and working. But as revertChanges isn't > > implemented I'm a little unclear about how it is intended to work. > > If I work with a store and saveChanges a dozen times, and then > > revertChanges once, what does reverting mean? Does it mean `go back > > to the state things were in when I started working with the store' > > or does it mean `don't do what I've been working on since the last > > save' or does it mean `undo what I did last save' or what? > > So the choices are: > - revert to time 0 of store usage > - revert the effects of last save > - revert changes since last save > > I was thinking the last one. That's pretty easy. In fact that's trivial; you just call BEGIN at the start of using the store and COMMIT/ROLLBACK when you hit one of the *Changes methods. Okay. It's a little weird in that there's no actual SQL statements run in between there in the case of a revert, tho (as they're all run on save and save commits the transaction). Oo, should revertChanges flush the object cache and generally reinitialize objects? You'll have a bunch of objects whose changes have been `reversed' but not really, and if you don't and use the revert changes since last save model, you can get into strange situations like v = store.fetchObject (Video, 42) v.setSpam (3) store.revertChanges () # logically undoes setSpam (3) v.setEggs (2) store.saveChanges () # danger of setting spam & eggs here > >o How do you run the tests? I'd like to be able to make my changes > > and then run all those tests to make sure I didn't break something, > > but I'm not entirely sure how to get them to go. > > python test.py > python test.py MKSpecificTest Thanks. <snip further description> - -- Graham Hughes <gr...@ly...> PGP fingerprint: 1F1D 0027 B835 E114 3F5B 2C7C 64D1 83A0 C5C7 312A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/> iD8DBQE60j/lZNGDoMXHMSoRAlkjAJ4saAY8H/+sNrrTay/4Fa891yv87ACgxOwM vprLJrbigxG4MhYBZXt/2fg= =t8G9 -----END PGP SIGNATURE----- |