So in addition to the docker env to play with drill and caravel at https://github.com/JohnOmernik/caraveldrill
We also have a Dialect going at: https://github.com/JohnOmernik/sqlalchemy-drill Now, this dialect doesn't do much but allow a connect using pyodbc, thus it's not something where you can dive in and use. Basically we are using it, based on a pyodbc access dialect to understand dialects and update pieces (and remove access pieces) as they cause issue for Caravel...it's an iterative approach... but it's how I learn so if your approach is to understand SQLAlchemy and write from scratch, this is not the Repo(s) for you... Right now we have in the caraveldrill repo: - Working Docker image that loads all the uniodbc, mapr odbc, caravel, pip, and caravel prereqs - It updates settings so MapR ODBC can talk to drill with the proper unicode - It installs caravel, has that working - It has a sample python script that validates that outside of sql alchemy and caravel, your settings for pyodbc are working, and also provides helpful connection strings for caravel - It DOES NOT install the sqlalchemy dialect in the sqlalchemy-drill repo. You have to clone that and install it in the container yourself using python setup.py install. - Once that is done, the connection test will work successfully, and now it's hacking on the dialect until we see pretty visualizations :) John On Mon, May 16, 2016 at 4:09 PM, John Omernik <[email protected]> wrote: > Ya happy to join the hangout tomorrow. > > On Mon, May 16, 2016 at 3:09 PM, Neeraja Rentachintala < > [email protected]> wrote: > >> John >> Great. Can we briefly look at this during hang out tomorrow. >> >> On Mon, May 16, 2016 at 12:26 PM, John Omernik <[email protected]> wrote: >> >> > AWESOME! Yep, that works and I like it better than using sys.options. >> Now >> > to dive in and play with the Dialect. >> > >> > Note, I will be uploading an unfinished dialect in my caraveldrill >> repo... >> > the goal isn't a production ready thing, but a skeleton (based on the >> > access one) of what a dialect is... The purpose is to evolve things as >> put >> > it all in one area for people to work with. As of now, I have no clue >> how >> > to trap statements with no FROM, but that's my first thing to work on :) >> > >> > Thanks for the help Veera! >> > >> > John >> > >> > On Mon, May 16, 2016 at 2:20 PM, Veera Naranammalpuram < >> > [email protected]> wrote: >> > >> > > Does this work? >> > > >> > > 0: jdbc:drill:zk=local> SELECT 'x' AS some_label from (values(1)); >> > > +-------------+ >> > > | some_label | >> > > +-------------+ >> > > | x | >> > > +-------------+ >> > > 1 row selected (1.41 seconds) >> > > 0: jdbc:drill:zk=local> >> > > >> > > -Veera >> > > >> > > On Mon, May 16, 2016 at 3:19 PM, John Omernik <[email protected]> >> wrote: >> > > >> > > > I suppose I could do select 'x' AS some_label from sys.options >> limit 1; >> > > > >> > > > any reason not to? Any other options? >> > > > >> > > > On Mon, May 16, 2016 at 2:18 PM, John Omernik <[email protected]> >> > wrote: >> > > > >> > > > > Does Drill have a "dummy" table (like dual) that we could test >> > against? >> > > > If >> > > > > we had that I could replace the that in a dialect (I think) >> > > > > >> > > > > SELECT 'test plain returns' AS anon_1 >> > > > > >> > > > > >> > > > > SELECT 'x' AS some_label >> > > > > >> > > > > >> > > > > SELECT 'test unicode returns' AS anon_1 >> > > > > >> > > > > >> > > > > SELECT 'x' AS some_label >> > > > > >> > > > > >> > > > > Drill is looking for a "FROM" :) >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > > >> > > -- >> > > Veera Naranammalpuram >> > > Product Specialist - SQL on Hadoop >> > > *MapR Technologies (www.mapr.com <http://www.mapr.com>)* >> > > *(Email) [email protected] <[email protected] >> >* >> > > *(Mobile) 917 683 8116 - can text * >> > > *Timezone: ET (UTC -5:00 / -4:00)* >> > > >> > >> > >
