On Fri, 27 Apr 2001, you wrote:
The real answer is since you are using a database you care about speed
so spend three minutes reading the docs/google for your particular
database vendor and implement whatever strategy is suggested
(AUTO_INCREMENT, ROWID, oid, SEQUENCE, before-row-insert
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
On Fri, 27 Apr 2001, you wrote:
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?
Paul Makepeace sent the following bits through the ether:
If it was that simple, someone would've done it -- DBI is a very
mature and competent module
That's the problem. It seems like people aren't content with writing
their own, slightly different, templating system, and have moved onto
On Fri, 27 Apr 2001, you wrote:
Paul Makepeace sent the following bits through the ether:
If it was that simple, someone would've done it -- DBI is a very
mature and competent module
That's the problem. It seems like people aren't content with writing
their own, slightly different,
On Fri, 27 Apr 2001, Robin Szemeti wrote:
On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
[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
Mark Fowler sent the following bits through the ether:
Don't see why this isn't possible
Indeed. All you need to do this is:
o bytecode and a virtual machine
o some way of instrumenting said VM to save interesting info
o ability to rewrite bytecode on fly
OK, I give you Perl, the Perl
On Fri, 27 Apr 2001, you wrote:
On Fri, 27 Apr 2001, Robin Szemeti wrote:
On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
[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
Friday, April 27, 2001, 1:09:05 PM, Robin Szemeti wrote:
RS but in the end (assuming that both
RS codesets use similar basic principles) you will not beat the speed of C
RS with anything other than hand optimised assembler. Now that is a fact.
Sounds much more like a function of the compiler to
Friday, April 27, 2001, 2:20:21 PM, Paul Makepeace wrote:
PM On Fri, Apr 27, 2001 at 01:51:38PM -0500, Mike Jarvis wrote:
Sounds much more like a function of the compiler to me. A
really good Fortran compiler would turn out faster code than a bad c
compiler.
PM But that isn't saying much.
On Fri, Apr 27, 2001 at 06:50:18PM +0100, Leon Brocard wrote:
OK, I give you Perl, the Perl debugger, and B::Generate. First one to
optimise Perl code (maybe replacing bits of Perl with XS on the fly?)
gets a pat on the back.
I think NI-S is working on it; see recent perl6-language discussion
On Tue, Apr 24, 2001 at 04:27:42PM -0700, Paul Makepeace wrote:
On Tue, Apr 24, 2001 at 12:28:42PM +0100, Dominic Mitchell wrote:
Don't forget that even if you could automatically change the API over,
you'd still have to change all the SQL in the API as well. Which is
probably just as
On Wed, 25 Apr 2001, David Cantrell wrote:
Trouble is, they all have non-standard extensions, which are *really* handy
and which you *will* use if you don't know any better. For example, MySQL
has AUTO_INCREMENT fields which are dead useful for id fields; the closest
Oracle equivalent
Mark Fowler sent the following bits through the ether:
Why you say don't know better, what should I use instead of this. Is
there any sensible way to do this in bog standard SQL that won't have a
massive perfomance hit on mysql?
The nice thing about SQL is that there are so many standards
On Wed, Apr 25, 2001 at 12:50:05PM +0100, Mark Fowler wrote:
On Wed, 25 Apr 2001, David Cantrell wrote:
Trouble is, they all have non-standard extensions, which are *really* handy
and which you *will* use if you don't know any better. For example, MySQL
has AUTO_INCREMENT fields which
Here's a perl question (OK, not really).. Is anyone aware of a
compatibility/wrapper library which a developer could use to take an
app using the MySQL API and with some (ideally) minimal munging turn
it into Oracle OCI or Pro*C code?
I'm faced with converting a couple of apps that have MySQL
On Tue, Apr 24, 2001 at 02:58:23AM -0700, Paul Makepeace wrote:
Here's a perl question (OK, not really).. Is anyone aware of a
compatibility/wrapper library which a developer could use to take an
app using the MySQL API and with some (ideally) minimal munging turn
it into Oracle OCI or Pro*C
On Tue, Apr 24, 2001 at 12:28:42PM +0100, Dominic Mitchell wrote:
On Tue, Apr 24, 2001 at 02:58:23AM -0700, Paul Makepeace wrote:
Here's a perl question (OK, not really).. Is anyone aware of a
compatibility/wrapper library which a developer could use to take an
app using the MySQL API and
On Tue, Apr 24, 2001 at 12:28:42PM +0100, Dominic Mitchell wrote:
Don't forget that even if you could automatically change the API over,
you'd still have to change all the SQL in the API as well. Which is
probably just as difficult a task, given how much SQL can vary from
product to
19 matches
Mail list logo
