Fork me on GitHub

I'm considering a new, streamlined API for (in a new namespace) to modernize it a bit and make it run faster (by, for example, defaulting to a raw ResultSet with various Clojure interfaces/protocols extended to it, as is currently an option for reducible-query). How many folks use the :entities and :identifiers options? Do you :entities for anything other than just quoting (to avoid conflicts with SQL reserved words)?


The old API will continue to exist 🙂 This is purely accretive.


Something with fewer "knobs and dials" could be quite a bit more efficient.


I think an interesting addition would be the ability to namespace key names with the name of the table they are from, which you can kind of hack in, but takes a fair bit of messing around


I think the way I have did that before with the existing jdbc interface is using the :read-columns option for reducible query to get a row like {:key [:table_name/key value]} and then map a function to throw way that map and rebuild it from the vals as {:table_name/key value}


You can specify the :qualifier option and it will give you namespaced keys back.


But, yeah, doing it automatically based on the table names would be nicer -- although in a general query where you can rename columns in SQL, it all gets a bit messier.


sure, but you sort of automatically already have a group of keys via the tables they came from


get-by-id and find-by-keys know which table you're querying.


and :qualifier will apply the same to all the keys in a join, but if you get the table name from the row metadata, keys from different tables in a join will have different namespaces


Yeah, I need to look at the metadata in more detail and see how broad support is across different databases.


even something like :read-columns, but returning a tuple of [key value] instead of value would make that kind of thing easier


In theory, I can just call (.getTableName rsmeta idx) and get the table name for any column in the ResultSet -- if it is known.


The v2 API could unconditionally return qualified column keywords perhaps...