[Glass] ODBC to GemStone and ODBC from GemStone

[James Foster]

> On Oct 2, 2013, at 7:08 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
> 
>> On Tue, Oct 1, 2013 at 4:30 PM, James Foster <James.Foster at gemtalksystems.com> wrote:
>> Hi Mariano,
>> 
>> The question of an ODBC interface for GemStone/S comes up periodically and is a particular interest of mine. It turns out that the hard part is not the Windows ODBC stuff (I've got a proof-of-concept that works with Excel, Access, etc. and sends queries to GemStone/S through the GCI library). The difficult part is translating SQL to Smalltalk and mapping heterogeneous collections of objects into something that looks like a fixed-schema table with homogenous rows of similar and simple columns (i.e., not complex objects). My proof-of-concept used a very simple schema and only supported enough SQL for the limited demo.
> 
> Indeed, I understand. Probably it doesn't help much but could could see how Glorp does such mapping. It is not the same case because Glorp has descriptions of the classes regarding the database structure so it is easier to figure out the SQL. But anyway...maybe you get out an idea from there....

I have thought of using that a bit since part of the task is making the Smalltalk collections map to tables. 

> mmmm now that I think, I think Glorp mapping is the other way around: from a smalltalk query, get out the SQL. Here is to get the smalltalk expression out of the SQL.

Exactly.

> At least there was a petit parser for SQL ;)

Where? I would find it helpful. 

>> The primary question is whether there would be commercial demand for an ODBC solution that would cover the cost of development (rough estimate of many person-months to get basic functionality, a few person-years to get something really polished).
> 
> Indeed. BTW, does GemStone offer a kind of out of the box solution to provide web-services? 

Nothing explicit. 

>> The approach I've typically taken and seen is to export a CSV file (comma-separated-values) from GemStone/S and let Excel handle things from there.
> 
> yes, this is exactly what I was thinking for my particular case: let gemstone perform all the queries/reports/logic and let a simple csv with the result. Then JasperReport/Excel or whatever reads it and does what he wants. 
> 
> Thanks James for you answer.  
>  
>> James
>> 
>>> On Oct 1, 2013, at 6:37 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>>> 
>>> Hi guys, 
>>> 
>>> I remember a presentation about GemStone status and future in which you mention ODBC. At that moment I was interested about it and I asked. It was supposed to be included in some version of GemStone. This "ODBC" you were talking about was NOT an ODBC client as I imagined, but the other way around: that any ODBC client from any language could query GemStone. So first question, was this released? what is the satus?
>>> 
>>> Say I want to build some reports using Java (JasperReports or whatever) would I need "GemBuilder for java"?  Seems a bit overkill to me since it is not a whole client/server application. That's why I was asking about ODBC. Of course, there could be other workarounds but just wondering.
>>> 
>>> Finally, I guess there is no generic ODBC client for GemStone right, so the only relational DB I can connect right now is Oracle (with GemConnect product)? Has anyway workarounded the scenario where you had to interact with another relational DB than Oracle?
>>> 
>>> Thanks in advance, 
>>> 
>>> 
>>> -- 
>>> Mariano
>>> http://marianopeck.wordpress.com
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131002/eff044f9/attachment-0001.html>