top | item 12834346

Django SQL Explorer

193 points| uyoakaoma | 9 years ago |github.com | reply

31 comments

order
[+] numlocked|9 years ago|reply
Well...this is a surprise. I wrote SQL Explorer :)

Glad folks are finding it useful!

Happy to answer any questions or take feedback/feature requests (I'm [email protected])! We use the heck out of this thing internally.

A couple fun notes:

1. Every SQL statement is logged as a QueryLog object. This really simple data model enables a ton of the functionality:

- unique, bookmarkable URLs for every single query (including ad-hoc queries)

- historic runtime/query duration reporting

- query versioning

- 'popularity' in the form of run-count

2. The 'snapshot' feature is incredibly powerful. Tick a box on a saved query and (assuming you have Celery), Explorer will the run query on a cron and save the results to s3. Super useful for mutable data. Like, if you have a product catalog and the prices sometimes change, but not very often, it's great to have a query of 'current prices' that snapshots once per day.

3. Queries are all exposed as CSV and JSON endpoints (with token auth). A great way to shuffle data between applications.

4. The only 'django-specific' part of this is that it introspects the Django app metadata to build the 'schema viewer' on the right hand side. If not for this one feature, this would just be a totally general-purpose query tool that happened to be built on Django. One day...

[+] lsh|9 years ago|reply
Just like to say that django sql explorer has been very useful in getting a few non-technical people (who know sql) investigating the state of our databases, their relations and attempting to express reports they need. I'm hoping their work will be easy to translate into Metabase 'questions' while I pull our reporting project together.

http://www.metabase.com/

[+] arikfr|9 years ago|reply
I hope you don't mind the self plug: I think Metabase has support for raw SQL, but if you find it hard to translate to Metabase "questions", it sure will be easy to translate into queries in Redash... In Redash you create visualizations from regular SQL queries (although we do support adding parameters and such).

https://redash.io https://github.com/getredash/redash

Disclaimer: I'm the author/founder of Redash.

[+] tlrobinson|9 years ago|reply
Hey thanks for mentioning Metabase, I work there. Not to hijack this thread, but I'm happy to answer any questions.

We do have raw SQL (and Mongo/Druid/etc) mode if that's your preference, or if you can't express something in our graphical query builder.

There's also a neat little feature that will translate your query builder query to the equivalent SQL to use as a starting point if you can't express something using the UI.

We also have parameters so you can parameterize questions (both graphical and SQL) on a dashboard.

Finally, we recently started added permissions and groups, so Metabase will be able to grow with your company. A lot more to come there too.

[+] abrookewood|9 years ago|reply
How is it different to Metabase? They look like they do very similar things. Can I ask why you are using both?
[+] viiralvx|9 years ago|reply
Something that we use at my job is Looker (https://looker.com/). While it's not open-source or free, I didn't know about the product until I joined and I love their features for data visualization and running ad-hoc queries. We just set a read-only user named 'looker' and its good to go. :)

Disclaimer: I'm not a Looker employee or anything, just a happy user of their product.

[+] numlocked|9 years ago|reply
(SQL Explorer author here)

We actually use Looker as well internally. It's a great tool. When we were smaller, Explorer fit our needs really well (I should hope so - since I specifically wrote it for us), but as we got bigger (~40 employees now) it's harder to manage a large number of reports, and we started getting a bit of a backlog of "please add field x to report y" engineering tickets. Looker has been a great solution to allow people to self-serve even more.

We still use the heck out of SQL Explorer as well, but Looker adds a ton of additional value (though notably, is not terribly cheap).

[+] thenaturalist|9 years ago|reply
Hey, we're thinking about switching our reporting to Looker. Would you mind sharing your impressions of the tool and maybe how your daily workflow roughly looks like?

You can shoot me an email via jankyri.com (link at the bottom).

[+] iriche|9 years ago|reply
Really fun to see this on HN:s front page - I started using this last week to give some non technical people access to some queries I usually run for them. Works perfect so far!
[+] numlocked|9 years ago|reply
Woohoo! Thanks and great to hear. If you have any feedback or suggestions, feel free to open a GH issue (...or a pull request), or email me directly: [email protected]
[+] agentgt|9 years ago|reply
An easy way to fix many of the "production" concerns is to run SQL explorer only on syndicated read only slave servers.

Most databases support slave servers.

Probably should be added to the readme.

[+] webmaven|9 years ago|reply
This looks like an interesting tool, and a great way to sharethis sort of knowledge internally.

I'm hankering after a SQLAlchemy version, though.

[+] madrox|9 years ago|reply
Well done! We built something similar at my company for the same purposes. This functionality is powerful for any team that wants easier data access for casual SQL users.
[+] nepsilon|9 years ago|reply
So this has nothing to do with Django, other than being built with it? It took me a while to realize that.
[+] numlocked|9 years ago|reply
(app author here)

It is tied to Django. When generating the schema information to show fields, etc, it introspects the Django application metadata. So in that sense it is tied to Django and expects to be querying a Django application DB. I would actually love to remove this requirement though, and have it just be SQL Explorer.

[+] webmaven|9 years ago|reply
What does something that does "have to do with Django" look like to you?