> If you write SQL using specific database extensions (i.e., non-ANSI SQL)
Access isn't the only problem here. Oracle 8 does not support ANSI style
joins. For example,
SELECT A.column, B.column
FROM A LEFT OUTER JOIN B ON A.id = B.id
Note that the Oracle JDBC driver does not support {oj } escape sequences.
Does cocoon or BOX have any scope for a translation layer of some sort?
Cheers,
Zulq.
-----Original Message-----
From: jarvisd [mailto:jarvisd]On Behalf Of Dave Jarvis
Sent: 18 November 2001 00:03
To: Jakarta General List
Subject: Re: Business-Oriented XML
Hello, Pete.
> punts on database neutrality and just prays that the SQL between databases
is
> identical. And of course everyone who has worked with SQL knows that this
is
> far from being true.
You got me on this one. If you write SQL using specific database
extensions (i.e., non-ANSI SQL), then you will be tying yourself to a
particular flavour of database. This is a very important aspect that,
on a practical level, seriously needs further research. In the ideal
world, of course, all SQL would port gracefully between database
vendors. ;-)
> How do you handle different quoting requirements for different databases?
How
> do you handle different databases id generators? How do you handle
difference
> X ?
If you really need to do something different, and you want to abstract
it so that it's all in one place, you can wrap it in a function
(generateNextID):
<var name="nextID" expr="generateNextID( 'table', 'column' )"/>
<sql>
<insert>INTO TABLE VALUES (?, 'John', 'Smith')</insert>
<using>
<value-of expr="$nextID"/>
</using>
</sql>
I will freely admit this isn't a great way (heck it isn't even a _good_
way); just showing it can be done.
I will also admit that it doesn't have all the necessary bells and
whistles to take into consideration specific implementation differences
across all databases. But even in Cocoon (and as you said, Turbine),
you can still do your own database-specific SQL which, in turn, lowers
the portability of the system. No matter what you do, if you give the
programmer full control over the SQL query, they'll always be able cause
system dependencies.
And lastly, I will admit I'm open to ideas on how this could be
implemented in a simple, straightforward fashion. :-) Useful pointers
to research is appreciated!
> I still see your project as basically a Generator for cocoon + cut down
> processing engine. I would be surprised if you could reach the performance
Yes. Simple, and quite focused. Did I mention small and fast? ;-)
> level of the Cocoon2 pipeline just because they have had a lot of people
> workin on it.
On a 96MB RAM, 266 MHz machine, 4GB 5400 RPM drive (I think), running
Mandrake Linux 8.1 (in low-security mode; X was not installed), Tomcat
3.2, JDK 1.3, Xalan 2.2 D6 (or so), and Xerces 2.0 beta 2, using a
remote Oracle 8i development server, it sustained a firing of more than
10 hits/sec. on the main page (using a 100MBit intranet). I could use
the site, but it was sluggish.
I tried again, using the same box, with hardware upgrades: 352MB RAM and
400MHz Pentium II. Under the same load of 10 hits/sec. the sluggishness
disappeared.
Using IBM's 'jikes' to compile, the single supporting JAR file (without
manifest information) is exactly 48651 bytes. The single servlet that
launches the processing engine is 6865 bytes. I could use Hashjava to
get it maybe 15% smaller ... but 41300 bytes vs. 48600 bytes is not
worth the effort.
I've tested the architecture against an HTML-based servlet-only site
with the exact same functionality as the BOX code. The servlets were
faster, but the difference in speed was less than a second. Keep in
mind the servlets have no extra transformation step -- they output pure
HTML to the browser.
I have no doubts about the performance of the architecture. Most of the
grunt work was already done for me (by lots of people whose work I
admire and appreciate): loading XML, parsing XML, rendering an XML
document, translating it into XSL, encapsulating HTTP, etc. The only
layer I add is a simple set of statements that allow people to talk with
a database, file systems, and remote servers. And I throw in a state
machine for good measure. The bottleneck isn't BOX. ;-)
How does Cocoon perform under the same minimal conditions as above?
Sincerely,
Dave Jarvis
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
