Hi Fernando, Fernando wrote:
Hello,
I'm new to OJB, and would like to know, from their users, the answer for
this questions:
a) Let's suppose I coded my entire app using ODMG and OQL queries, and
tested in Oracle 8. Some OQL queries are really complex, but they work on
Oracle. Then I want to deploy my app for Sybase SQL Server 11, whose queries
are very limited compared to Oracle. The question is: is it guaranteed that
all OQL queries will keep running on Sybase?
Yes, all queries will be running
Of course I will test my app in Sybase before deploying, but should I expect that some queries will not run due to Sybase limitations?
No, ll queries will be running
We don't have a complete OQL support. The OQL statements are parsed into OJB query expressions (an abstract syntax tree representation of queries). So the OQL capabilities are limited by the Query expressions.b) If the answer of the previous question is "Yes, all queries will be running", then I would like to know how OJB implements portability. I suspect of 3 options: b.1) Limiting OQL query complexity, so that OJB users are prevented from coding queries that would not be portable due to database limitations. For example, Oracle supports "select ... from (select ...)", and Sybase SQL Server 11 doesn't. So, OJB will not support "select ... from (select ...)". People that only use powerfull databases pay the portability price in development.
E.G.: with OJB you can only retrieve complete persistent Objects from the database. you cannot retrieve some attributes only...
But this restriction is not imposed by target database restrictions. It's a design decision to keep the query mechanism simple.
You got it!b.2) Emulating using a common subset of database features. The query is parsed and spans to one or more SQL queries needed to run. Each SQL query uses only a subset of database features, which are common to all supported databases. People that only use powerfull databases pay the porbatility price in performance.
The above mentioned expressions are translated into platform specific SQL by the SqlGenerator. The SQL generation process can be slightly modified by the PlatformImplementation is use. SO the SQL generated for Oracle will look different from Sybase SQL.
So the performance impact is reduced.
b.3) Emulating using an understand-and-optimize method. The query is parsed and checked. Then it spans to one or more SQL queries, depending on the database. If it's a powerfull database, the SQL queries will be small in number and very complex. If it's a poor database, the SQL queries will be great in number and not too complex. The portability price is paid by OJB development.
Too much work for lazy guys like me... cheers, Thomas
There may be other options too, and more than one may be used. I just want to know how OJB does. Thanks in advance, Fernando. -- 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]>
