Clojurians Log v2
java
@polymeris Maybe the JDBI? But i’m also curious, i bet @seancorfield would be a good person to ask.
I show hugSql to java devs and i feel like i get blank stares. Like either they dont get the problem or i dont. I’m writing the same jdbc boiler code all over the place. I’m sure there are lots of ppl in the java community that have ways to bring in standard defaults
But i haven’t dug into postgres and the jdbc to be anything close to an authority on what looks good in a demo vs what works well over time…
Thanks! Jdbi takes a different approach than Yesql, but looks interesting. My colleagues mostly reach for full-fledged ORM solutions. Something like this could serve as gateway for a more SQL-centric approach
@polymeris I welcome any feedback on these ideas. I’m dealing a lot with sql and java at the minute so i’m very invested in these issues… Taking a step back. I think we (devs) have some fundamental constraints. * Our core language constructions cannot help us construct SQL queries as their strings. Pile that on top of a lot of other issues and you end up wanting something that looks like Datomic. * OOP languages (java at least) want you to model data with classes, classes to my knowledge can’t dynamically conform to their stimulus (adding or removing data). Of course, collections in java have this interface, so why not use them intead? Do enough of that introspection and you will find that the idea of a class isn’t that useful at all (polymorphism is a different abstraction) and you abandon classes it all together (and were we are in #clojure) ORMS fall down because most OOP languages don’t map well to the grammar of SQL. HugSQL ignores that issue by just using sql and returning the results in clojure data types. Something like HoneySql solves the problem of making the sql compossible within your language but i’m not sure what the costs of that might be or where it fails to work as expected. For instance, postgresSQL is different then mySql, i doubt korma handles those differences… I think mixing HoneySql and HugSql would be acceptable given they handle different issues and the core problem rests at a deeper level then the application developer can tackle. edit korma-> honey
Most of that is me trying to interoperate Rich Hickeys work.
Honeysql does a pretty great job at that first one in my experience.
Know about Java libraries? Me? 🙂 I learned Java back in the 1.1 days and pretty much moved off to other languages around Java 5 so I don't pay attention to that ecosystem, except where I need something for Clojure that doesn't seem to have a Clojure version... sorry.
I think i said korma but meant honeysql
FWIW, I'm in the camp that stares blankly at HugSQL -- it doesn't feel like it solves a problem I have. Maybe I just don't see SQL strings in my code as a problem? When I have code that operates on the database, I like to see what the query is right there. I don't want to go find a SQL file that contains something that gets turned into a function that my code is calling. With HugSQL, you lose jump-to-definition in your IDE/editor.
@polymeris Perhaps this is a useful SO thread for answering your question? https://stackoverflow.com/questions/1544335/java-storing-sql-statements-in-an-external-file /cc @drewverlee
Axamol and iBATIS both look like ColdFusion markup to me 🙂
@seancorfield Well i get back syntax highlighting for my sql! how would i know its a reserved word other wise 🙂. Idk i felt hugsql was almost no cost for some nice syntactic sugar and boiler plate removal. But as i haven’t used it in anger, i’m really just hoping. I’m guessing you have less boiler plate then i’m currently dealing with.
I don't consider (jdbc/query db ["select some stuff here = ?" 42]) to be boilerplate... what boilerplate are you referring to? (and we should probably take this to #sql at this point)