Hi
Did some more work on the
'ON [DELETE|UPDATE} SET [NULL|DEFAULT]' stuff.
1) processCreateTable and processCreateFk now understand
the SET [DEFAULT|NULL] option.
2) procressCreateTable throws
a COLUMN_TYPE_MISMATCH exception if someone tries
to specify an 'SET DEFAU
Thanks Sebastian,
I will apply these patches to the CVS soon.
I think we can avoid infinite recursion in cascading deletes fairly easily.
Regarding other actions I must see what can be done. In general, if we can
use the graph of references as opposed to the actual rows, the solution
would be mor
I have committed the patches to hsqldb-dev HEAD and investigated the issues
of circular references to some extent.
On of the issues that I took into consideration for ON DELETE CASCADE was to
avoid heavy use of memory. The tables can be CACHED and quite often deleting
one row in a top level table
I'll be offline for the next 2 weeks
Doewsn't mean I'm not interested anymore
in participating. Simply means I'm on
vacation wothout an internet connection.
(yes there are such thinhs :-) )
Cheers
Sebastian
--
**
Dr. Sebastian Kloska
Head of Bioinformatics
Hi,
I've created a patch against the hsqldb-dev branch of CVS which allows the
code to compile under JDK 1.4, I'm not sure if it's any use, but I thought
I'd post it just in case.
Most of the methods throw a SQLException stating "Method not implemented",
I'll work on these slowly, but I initially
I'm working on some Linux scripts in hsqldb-dev. I need the same script
to be run with multiple names, but CVS can't handle hard or symbolic
links. Anybody know if we have a procedure to handle this, or if there
is some method that will "work"?
I could, of course, just copy the file (x - 1) time
Thanks,
The code compiles under JDK 1.4. To enable this, however, you need to
compile it first with Ant (only once) with your JAVA_HOME system variable
pointing to the JDK1.4 installation. This will modify the sources and remove
comments from the JDBC3 methods that are already there. You can also
Fred,
Is it not possible to implement code in such a way that it can compile under
all JDKs without switches?
The reason I'm asking is that I can see a lot of benefit in having a single
codebase that compiles on all platforms without needing the switch scripts.
Al.
- Original Message -
Is there any reason the script name needs to change?, Can you not make the
first command line argument the value for whatever you're currently using
the script name for and then change the first argument using xargs (or
something similar)?
Just a thought.
Al.
- Original Message -
From: <
The short answer is it is not possible due to the changes in JDBC interfaces
in different versions of Java. Developers always ask this, but we would
either have to maintain two versions of some files and use conditional
compilation, or have one file containing two versions. We use the second
option
I've been consulting with Fred, and that's what I'm doing.
The reason I wanted to differentiate functionality by arg 0 was for
backwards
compatibility. The new "switchjdk.sh" replaces switchToJDK11.sh +
switchToJDK12.sh + switchToJDK14.sh. But fortunately, Fred says there's
no need to permit con
FYI, I'm currently working on a generalized build script for UNIX which
will automatically invoke the code-switcher script. So, for UNIX users
without Ant, it'll take just one command like
buildjar.sh 1.4
to rebuild everying and make hsqldb.jar. I will also build in some
dependency smarts s
12 matches
Mail list logo
