Hi All,
I'm evaluating the extending of Derby for use as a JDBC access path to a
non-SQL data engine. Conceptually, what I need to do is a CREATE TABLE
which reflects the metadata of the result set which will be returned by
the non-SQL engine, and then intercept SELECT requests to this table,
Frank Griffin wrote:
Hi All,
I'm evaluating the extending of Derby for use as a JDBC access path to a
non-SQL data engine. Conceptually, what I need to do is a CREATE TABLE
which reflects the metadata of the result set which will be returned by
the non-SQL engine, and then intercept SELECT
Rick Hillegas wrote:
It sounds as though table functions (the Virtual Table Interface you
mention) might be a good fit for this job.
Thanks for the quick response, Rick. I'll dig into the material you
mentioned, and I'm sure I'll be posting again :-)
Hello
I had some discussions with Satheesh on this issue. A temporary solution
for developing this tool could be to support both approaches for now by ading
an optional -DddlUtils option and if specified, DdlUtils will be used
otherwise,
it will be a standalone tool using Metadata and system
Satheesh Bandaram wrote:
Jean T. Anderson wrote:
One thing to consider is DdlUtils is database agnostic. For example,
adding support for create view doesn't mean just adding it for Derby,
but also adding it for every database supported (see the list at
Daniel John Debrunner wrote:
Satheesh Bandaram wrote:
Jean T. Anderson wrote:
One thing to consider is DdlUtils is database agnostic. For example,
adding support for create view doesn't mean just adding it for Derby,
but also adding it for every database supported (see the list at
Daniel John Debrunner wrote:
Isn't the point of Google summer of code to introduce students to open
source development, and this switch to ddlutils and additonal community
involvement is typical of open source? Scratch your own itch but also
benefit the community as well.
Dan
I am all for
I'm all for helping out other projects, but IMHO Derby could really use
this migration tool. We could let the DDL team know these issues exist,
participate in discussions with them, while at the same time scratching
our own itch and getting a migration tool done before Ramin disappears...
David Van Couvering wrote:
I'm all for helping out other projects, but IMHO Derby could really use
this migration tool. We could let the DDL team know these issues exist,
participate in discussions with them, while at the same time scratching
our own itch and getting a migration tool done
+1 on that (from a ddlutils committer, with way too little time on his hands..)
:)
Mvgr,
Martin
Bryan Pendleton wrote:
The DdlUtils tool seems not be capable of migrating views, CHECK
constraints, and stored procedures. I would like to know what do you
think if DdlUtils tool can be reused
Hi Bryan,
I am not sure this would be feasible given the amount of time I have
to finish this project as well as my familiarity with DdlUtils code
base. But if everybody agrees to it, I can start working on it.
Thanks
Ramin
On 7/11/06, Bryan Pendleton [EMAIL PROTECTED] wrote:
The DdlUtils
Ramin Moazeni wrote:
Hi Bryan,
I am not sure this would be feasible given the amount of time I have
to finish this project as well as my familiarity with DdlUtils code
base. But if everybody agrees to it, I can start working on it.
Hi Ramin,
I think that even if your project scope was
Hi David
I do not believe the split will be exposed to the normal user.
However, in case of an error, the user might have to follow two
different paths to fix the problem. For example, modifying xml files
for ddlutils component and modifying sql statements
for the DatabaseMetadata approach.
I
Ramin Moazeni wrote:
Hi Bryan,
I am not sure this would be feasible given the amount of time I have
to finish this project as well as my familiarity with DdlUtils code
base. But if everybody agrees to it, I can start working on it.
One thing to consider is DdlUtils is database agnostic.
Jean T. Anderson wrote:
Ramin Moazeni wrote:
Hi Bryan,
I am not sure this would be feasible given the amount of time I have
to finish this project as well as my familiarity with DdlUtils code
base. But if everybody agrees to it, I can start working on it.
One thing to consider is DdlUtils is
Jean T. Anderson wrote:
One thing to consider is DdlUtils is database agnostic. For example,
adding support for create view doesn't mean just adding it for Derby,
but also adding it for every database supported (see the list at
http://db.apache.org/ddlutils/database-support.html ).
This is
Hello
As per my earlier post regarding the design document for MySQL to
Derby Migration tool located at
http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument, I
proposed two approches: 1) based on the use of DatabaseMetaData and 2)
using DdlUtils tool.
The DdlUtils tool seems not
If this is the simplest approach in terms of design and code re-use it
sounds good to me, *as long as* the user doesn't have this split exposed
to him/her, and instead sees one seamless tool and user experience.
In particular, if Things Go Wrong, what is the user flow/experience --
how does
The DdlUtils tool seems not be capable of migrating views, CHECK
constraints, and stored procedures. I would like to know what do you
think if DdlUtils tool can be reused for migrating the tables and
Indexes, and use the DatabaseMetadata for migrating views and stored
procedures? .
Perhaps
19 matches
Mail list logo
