Hi Tim, I've had a closer look at CMIS-SQL. I'm not sure if I got the whole picture, but I feel that this is a very limited SQL dialect with almost no functionality, or am I missing some important aspects? Also, how well is CMIS adopted?
Before thinking about adding a contribution, I would like to assess its true value. Currently, new SQL dialects are not very easy to integrate in jOOQ, as jOOQ performs a lot of SQL syntax transformation to simulate functions and SQL clauses to standardise dialects. This effort is only worth the pain if I can get most of the integration tests to run. Cheers Lukas 2013/6/7 Tim Webster <[email protected]> > Hi Lukas - any addition would obviously have to implement the CMIS SQL > extensions. > > I wouldn't mind being involved in this (contributing, etc) - not sure > where to start though - any suggestions? > > Tim > > > On Friday, June 7, 2013 11:34:57 AM UTC+1, Lukas Eder wrote: >> >> Hi Tim, >> >> 2013/6/7 <[email protected]> >> >> Hi, >>> >>> I posted this over at the QueryDSL group and didn't get much of a >>> response - was wondering what everyone here thinks of it...?: >>> >> >>> I'm currently working on a CMIS implementation. For those not familiar >>> with CMIS, it is an open standard for Content Management (documents, files, >>> media, etc). Content is stored in a repository which is CMIS compliant. >>> There are several big-name vendors that provide CMIS systems (IBM, >>> Microsoft, etc). >>> >>> One of CMIS main features is the ability to query the repository using >>> SQL (SQL 92 compliant). Currently there is no abstraction layer for >>> generation of this SQL, the queries must be built 'by hand'. It would be >>> nice to have a QueryDSL-like implementation to be able to write these >>> queries. >>> >>> However, there are some differences between CMIS and databases: >>> >>> - A CMIS repository is not a database, and querying from a client point >>> of view does not require JDBC. All we need is the SQL. >>> >>> - Will QueryDSL only support back-ends that can be interfaced by a JDBC >>> driver? >>> >> >> Yes, jOOQ relies on JDBC for SQL execution. You can still use jOOQ for >> SQL rendering only, if deviating execution APIs are provided by CMIS >> implementations. I could imagine, though, that it shouldn't be too hard to >> implement JDBC for CMIS, wrapping existing non-standard APIs inside. >> >> >>> - Type-safety. CMIS has object types, and these have property >>> definitions. These could be analogous to database tables and types could >>> theoretically be generated against them. >>> >> >> I'd have to dig further into CMIS details to take a stand on that. >> >> >>> - I'm trying to work out if this belongs here or in the OpenCMIS project >>> (Apache Chemistry). If it isn't suited to QueryDSL because of the lack of >>> database or JDBC, perhaps it would be more appropriate there. >>> >> >> Clearly, jOOQ wouldn't implement JDBC for CMIS, but rely on a possibly >> not-yet-existing JDBC driver. So the JDBC driver should be implemented in >> Apache Chemistry. If you would need such an implementation any time soon, >> you could P.M. me for an implementation effort, and possible contribution >> to Apache. >> >> >>> So, this is just something I'm thinking about and would greatly value >>> any thoughts or feedback from the experts..:-) >>> >> >> What I can tell you is that I had recently evaluated feasibility of >> supporting JCR-SQL2 in jOOQ as a personal interest that evolved from my >> current contracting position at Adobe for the Adobe Experience Manager. I >> have come to the conclusion that JCR's promise of providing a SQLesque >> querying language is not a good match for jOOQ. >> >> Looking at CMIS's SQL dialect, however, I feel that there is some >> potential of integrating, as the promise to implement SQL-92 is a bit more >> "trustworthy". I have registered a feature request for this evaluation: >> https://github.com/jOOQ/jOOQ/**issues/2507<https://github.com/jOOQ/jOOQ/issues/2507> >> >> Given my (rather short) JCR and content management experience, I think >> that your suggestion could be a real value addition to jOOQ! >> >> Cheers >> Lukas >> > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
