Re: [Exist-development] thoughts about next steps with RDBMS integration

[James F. <jam...@gm...>]

ok this probably has to be a bit lower level then, because we want to
make it as natural as possible for end users to apply XQuery ...
probably best to work through this via chat.

J

On Wed, Mar 31, 2010 at 3:55 PM, Adam Retter <ad...@ex...> wrote:
> Sure you could create a sql-collection() function using XQuery and
> manually manage collection.xconf documents in a virtual hierarchy like
> /db/system/sql/db/...
>
> On 31 March 2010 14:43, James Fuller <jam...@ex...> wrote:
>>
>>
>> On 31 March 2010 15:03, Adam Retter <ad...@ex...> wrote:
>>>
>>> On 31 March 2010 06:45, James Fuller <jam...@ex...> wrote:
>>> > whilst doing xproc development, I have had great fun integrating some of
>>> > eXist existing extension functionality as extension steps ... a thought
>>> > occurred to me about the current state of integration with RDBMS.
>>> > Currently we have the nice SQL extension module (written by Adam Retter)
>>> > which uses JDBC to query a relational database ... this means we can
>>> > easily
>>> > query an RDBMS through xquery using SQL statements. I think this module
>>> > enables a lot of scenarios but misses off the primary scenario for the
>>> > masses of people out there with data currently existing in RDBMS but
>>> > want to
>>> > use XML database.
>>> > I would like to
>>> > install eXist and provide in some registry a connection string which
>>> > effectively 'mounts' the RDBMS as a collection ... from which here on
>>> > out I
>>> > can use pure xquery to work on. For now a read only view of the data is
>>> > all
>>> > I need but someday I would like to be able to do updates as well on the
>>> > RDBMS data. Lastly I should be able to configure cache characteristics
>>> > if
>>> > the database connection is intermittent'
>>>
>>> Phew!!! For a moment then I thought you were going to ask for a SQL
>>> layer atop eXist-db and a JDBC driver for eXist-db.
>>>
>>> This would actually be pretty easy to achieve :-)
>>>
>>> Imagine the collection namespace root starting at /sql as opposed to /db.
>>>
>>> Configuration could go into
>>> /sql/system/sql/{database}/{schemaName}/{tableName}
>>>
>>> And the database configuration could again be defined in conf.xml
>>> files in the /sql/system/sql collections. Caching and connection
>>> property characteristics could also be placed in conf.xml files in the
>>> appropriate sql configuration collection.
>>>
>>> Almost all of the existing infrastructure could be reused. You would
>>> simply need to extend the Collection function so that in the case of a
>>> "/sql" collection it defered the document set building to code that is
>>> very similar to that of the sql module. You would also need to come up
>>> with a collection xml serialization scheme for displaying the
>>> available sql schemas and tables as sub-collections but thus should
>>> not be very hard and should be as close to possible (if not the same)
>>> as the existing ones for the db collections.
>>>
>>> This is quite exciting - I like :-)
>>>
>>> Can I help?
>>>
>>
>> thx Adam for teasing out the detail ... this is a cool way to approach it
>> ... I would appreciate a chat to discuss; my initial thoughts were to create
>> an XQuery app (using sql extension module) to achieve the above ... its a
>> bit high level for my tastes for this kind of thing, but perhaps the best
>> first step.
>> J
>> J
>
>
>
> --
> Adam Retter
>
> eXist Developer
> { United Kingdom }
> ad...@ex...
> irc://irc.freenode.net/existdb
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Exist-development mailing list
> Exi...@li...
> https://lists.sourceforge.net/lists/listinfo/exist-development
>