Hacker News Reader

Comment by pron | Hacker News Reader

Nice! Can we have a JDBC driver for this?

Someone should make an ORM wrapper. Perhaps with one of those trendy fluent APIs, so you can just pipe the output from one command as input to the next.

Hahhahahahhahahahahaha

Was that a joke? If there's a general purpose querying mechanism for OS internals, does using JSON strings in a proprietary protocol that you then have to parse make more sense than JDBC? JDBC is the closest we have for a standard RDBMS access API, and it's got mechanisms that can be helpful if you want to speed up query execution (and waste less resources) like prepared statements. Plus, there's tons of visualization software for it already.

Yeah it was just a joke, on the fact that ORMs are so popular because people think learning SQL is too hard, but if you actually make a fluent ORM then that's basically exactly what UNIX is to start with.

Except this project takes the SQL approach, not the UNIX approach, and the most popular SQL API is JDBC. Also, I don't know if ORMs are still popular, but their original goal had little to do with simplifying SQL and a lot to do with trying (unsuccessfully) to reconcile the relational model with the OO model, and to save application developers the need to do the translation manually.

This project currently has a proprietary C++ API, so why not standardize with JDBC (at least for those making use of the JVM)?

Of course, someone is going to have to make a command line tool for easily interacting with this wrapper over a shell...

This uses SQLite virtual tables with a substantial amount of native code, so I imagine getting the existing SQLite JDBC drivers that rely on JNI would be a lot of work. Using a client/server model would probably be easier, though I haven't seen an existing server/driver combo for SQLite.

One idea is to make a PostgreSQL Foreign Data Wrapper (FDW) that would allow using PostgreSQL JDBC (and ODBC) drivers.

Reply on news.ycombinator.com