From: Andrzej J. T. <an...@ch...> - 2010-03-31 14:14:07
|
Adam said: > This is quite exciting - I like :-) I agree...the concept is intriguing. > 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. I think this is not a feature that will be of general interest to all eXist users, and should not be part of the core.....an external extension/plugin would make more sense, so that those that want to integrate with a RDBMS can just install the plugin and get the integration functionality. In that regard, I think the configuration should stay out of the main conf.xml and be put somewhere else, specific to the extension module. My 2 cents worth. > 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. One thing to keep in mind is that processing of in-memory fragments (which would be created from the xml data coming from the RDBMS) are much slower than native xml documents stored in eXist. Maybe this will provide some impetus to optimize processing of in-memory fragments a bit more, which would be a "good thing". ;-) -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: Adam R. <ad...@ex...> - 2010-03-31 14:15:57
|
On 31 March 2010 15:14, Andrzej Jan Taramina <an...@ch...> wrote: > Adam said: > >> This is quite exciting - I like :-) > > I agree...the concept is intriguing. > >> 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. > > I think this is not a feature that will be of general interest to all eXist users, and should not be part of the > core.....an external extension/plugin would make more sense, so that those that want to integrate with a RDBMS can just > install the plugin and get the integration functionality. > > In that regard, I think the configuration should stay out of the main conf.xml and be put somewhere else, specific to > the extension module. Sorry I orginally meant 'collection.xconf' and not 'conf.xml' -- Adam Retter eXist Developer { United Kingdom } ad...@ex... irc://irc.freenode.net/existdb |
From: Andrzej J. T. <an...@ch...> - 2010-03-31 14:28:02
|
Adam: > Sorry I orginally meant 'collection.xconf' and not 'conf.xml' Oh...OK! That makes a lot more sense and would be a good place to put that kind of stuff! Great idea, Adam! -- Andrzej Taramina Chaeron Corporation: Enterprise System Solutions http://www.chaeron.com |
From: James F. <jam...@ex...> - 2010-03-31 21:21:13
|
done some further analysis on this and have come to a few 'forks in the road' * Adam Retters vision of /sql/system/sql/{database}/{schemaName}/{tableName} is great ... I would amend this too something simpler like /sql/{database}/{schemaName}/{tableName}/ and this can be the concept of a mounted database from anywhere in collection hierarchy. * this also means we get REST and friends entrypoints * additionally, we may want an alternate configuration e.g. if we consider introducing the concept of a new protocol e.g. rdbms:exist:////sql/{database}/{schemaName}/{tableName}/ which leaves us a bit more wiggle room instead of a mount point in the database e.g. we probably want to make sure people know when an rdbms is being queried in some situations. * from an xpath, xslt and xquery point of view using this protocol should mean nothing special is needed (other then initial setup) to use data from rdbms * I agree with Adam Retters approach of lazy eval though I would like to investigate using an xpath parser approach that generates sql statements ... probably could use a lot of Adam's existing sql extension for the underneath bits * as for registering and configuration I think if its a 'mount' point in the database approach then we can use collection.xconf which could have a snazzy xquery app behind it for CRUD entries. Otherwise the rdbms:exist protocol would be configured 'elsewhere' ok, now reality .... my plate is full (of xproc) and I probably should not get distracted ... so anyone who wants to pick up and run with this tidbit feel free, I have decided to step away from this for the time being. J |