From: Ian B. <ia...@co...> - 2003-10-01 02:27:07
|
On a more general note, I'm happy to add Oracle support, but as a backend it won't receive the support from me that the other databases get. I have all the currently supported databases installed on my machine, and regularly do regression tests (and it's not uncommon for me to break something for a single database). But I'm not going to be able to do that with Oracle. So it'll require someone (one of you, or someone) to take up maintenance at least for that specific backend, and I'd imagine that CVS will generally be less stable for that backend (though we should at least be able to sync everything up before a release). The same is true of Sybase, which I think Sidnei is working on some. (And I'm just hoping that no one wants to use SAP DB ;) But anyway, Oracle support would still be cool. On Tuesday, September 30, 2003, at 04:06 AM, Dirk Evers wrote: > Hi, > > I also started to work on an Oracle version of SQLObject a few days > ago, > also using cx_Oracle. > > Problems I encountered are the slice notation > access to tables, because Oracle does not have anything like > LIMIT and OFFSET. Workarounds need a more complex SQL statement with > the original statement included as a sub-select. Not very nice! > This makes it necessary to overload functions at a higher level in > SQLObject > -- i.e. queryForSelect -- because the added statement is not just an > added suffix. > (Haven't implemented this yet.) Firebird required this as well. The methods are slightly different now, and might make it more workable. I'm surprised Oracle doesn't have anything to make it easier... but then it's weird the things you get used to without realizing they aren't universally supported. > Moreover, Oracle does not know anything like AUTOINCREMENT for the > PRIMARY KEY > statement, which makes things a tad more complicated. I used sequences > to > implement this. I was just about to start on the columnsFromSchema > functions > when I read your email. :-) Yes, that's what Firebird does, and what Postgres used to do. But you probably already figured that out. > John, let's compare our code changes to SQLObject and take it from > there. > I would be very happy to see an Oracle version of SQLObject come to > production > very fast! |