Open johnmyleswhite opened 10 years ago
Hey John, do you think we should move ODBC to be DBI compliant? Or is it kind of it's own thing since it was microsoft's version of DBI? I'd be ok migrating ODBC over, but I may suggest DBI adopt a change or two to make it less hassle (I've had the chance to look over DBI.jl somewhat, I just have a few suggestions...).
I'd really love to make ODBC be DBI compliant and also make DBI ODBC compliant. In general, the DBI design probably needs a few changes.
Awesome. I think a good way forward is I can start a dbi
branch on the ODBC package and start thinking about the combining of abstractions. I'll try to open up some issues/comment over the next little while, but it may take longer to actually implement the code. In general, I think this is a really good step forward though. The more coordinated we can be, the better the user experience will be when they realize that no matter the db they use, it's the same interface. Even when we have a native JuliaDB someday :)
Yeah, generic DB access is a huge plus.
Worth reading while we clean up DBI:
I mostly worked from the Perl documentation, since I know Perl's DBI better than Python's equivalent.
I'm willing to help out, though I'm probably better at testing at this point than developing until I get more comfortable with Julia.
Testing will be really helpful, especially with SQLite3, which has changed a lot in the recent past.
One thing that's unfortunate is that some of the functionality I'd like to provide in DBI for use in object-relational mappers requires custom builds of SQLite3, because the information used by the current table_info
function isn't available without a custom compilation step.
Do the DBs need to be created with the custom-compiled SQLite3 or do you just need the custom version for access? It would be perfectly reasonable to distribute the custom build with the SQLite3.jl package.
Unlike John, I have the most experience with Python's DB API 2.0. I don't know about Perl, but Python has been exceedingly successful in getting widespread adoption of the standard interface, so it's my inspiration.
Yes, we should probably distribute the custom binary since it's just the binary that matters, not the database.
FYI: GitHub has trouble keeping up with the number of e-mails it's supposed to send me. So it drops about 50%. If I ever seem to not respond, it's often because I didn't see comments in a thread. I didn't, for example, get an e-mail about your comments, @iamed2 and just noticed it by refreshing this issue.
how do I get DBI.jl into my project, is not in METADATA.jl; or should i just include the file?
DBI isn't ready for release. If you'd like to use it, you'll need to work from the relevant Git repositories directly.
Don't forget the Julia Redis client (https://github.com/jkaye2012/Redis.jl) - I've used it and it's pretty good.
Logo?
That's awesome!
I set it up already. It's just a little too large to render fully, so a smaller size would be great. It's about 20% too large I'd guess.
One other request: can you explicitly provide a license for the image so we're totally safe using it?
Better yet, an SVG so it's usable at any size, if that's something you can do. Looks great!
Great. I have posted an SVG version at https://gist.github.com/catawbasam/92d25c84fa3ea70bcf65
The license for the image is MIT. (The title of the gist contains the same license notice)
Here's a smaller PNG:
Sorry to keep changing things, but can we make the canvas a square? I think that might be the reason GitHub keeps clipping off the sides.
Here you go:
Perfect! Thanks again. This logo is amazing.
So, when will there be nice stickers that say "Julia DB" with that very good logo above? :grinning: :+1:
Hey all, please see https://github.com/jkaye2012/Redis.jl and https://github.com/jkaye2012/Redis.jl/issues/19 in particular. Thoughts?
@jkaye2012 seems willing to move Redis.jl to JuliaDB. Anything holding that back form happening?
Let's use this issue to keep track of which databases we support and which implementation is canonical.
Non-standard database / SQL query systems: