On Fri, Apr 27, 2001 at 09:38:45AM +0100, Robin Szemeti wrote:
> but of course .. however the topic was (somewhere along the thread)
> related to portable methods to try and keep from having to change all the
> SQL between different db version.
Why do this? Unless you're using the db in a toy capacity (which is
fair enough: see PHP) it's like using Java when you could be using
custom DSP hardware.
[side note: I did just see a bizarre thread in macosx-dev where
one guy claimed his FFT code was executing faster in Java than C
because its interpreter used runtime info to optimize it. Search on
'informal benchmarks']
> the blocking anly occurs occasionally, ... if you do it sensibly (get all
> the data ready .. {lock, get max, insert, release} the lock period is
> tiny. and not really an issue.
There are enough assumptions here to make me again suggest you use
a vendor-specific route :-)
> however I stll prefer my method (implement it as a 'library' wrapper
> class on DBI with the appropriate (AUTO_INCREMENT, ROWID, oid, SEQUENCE
> or whatevr) technique and a library::insert($sql,@args) method) and then
> you just have to plug in the approprate wrapper between your app and
> todays choice of DB and in theory the app can stay the same.
If it was that simple, someone would've done it -- DBI is a very
mature and competent module. Go check out Automatic Key or Sequence
Generation in the DBD driver feature summaries and you'll see why
it's hard to encapsulate this: they're all sooo different.
Paul
