Support for multiple vendor-specific features. about honeysql

[ddellacosta]

So I have to think about this some more, but @jrdoane, why do we need an "engine" parameter vs. simply a namespace that you would include, like honeysql.format-postgresql or the like? Seems like all you need is a set of specific extensions which use built-ins like honeysql.format/fn-handler, honeysql.format/format-clause and the like. But I could be wrong about that--are there any vendor-specific features that require more customization than the built-in extension helpers can provide?

Ditto liking that whatever the solution may be, could provide an answer to the DDL problem.

[ddellacosta]

Ping @jkk and @MichaelBlume --this has been hanging out for a while and seems to impact a bunch of open PRs. Any thoughts as to the various options discussed above? I fundamentally would prefer to have vendor-specific libraries which you can include along with HoneySQL, vs. a vendor specific set of "engines" integrated into the main HoneySQL library. Would like to hear some other ideas.

[ddellacosta]

Related: #86, #96, #81

[MichaelBlume]

@ddellacosta I'm pretty much in agreement, and I think honeysql already has what it needs to support those libraries.

[jrdoane]

While I do agree that third-party "plugin" libraries would be nice, my concern is more of a specific nature. It's really not hard to add vendor specific functionality to HoneySQL but, the question is, could you use multiple vendor specific features at the same time? That is, how do you handle the case where you might need to generate not just PostgreSQL but, TransactSQL or MySQL as well in the same application? I suggested something like an engine because it wouldn't tie the entire library to a single implementation for a particular vendor. For cases like mine where the primary Clojure application I maintain is integration between systems, it wouldn't be outside of the realm of possibility that I would need to interface with more than one kind of database.

So, I'm all for doing stuff the way it is right now but, I do think that if you dig deep enough simply extending a singular multimethod or protocol alone might not offer enough flexibility to support generating SQL for multiple vendors in the same application. I'm sure it's an edge case but, something worth considering.

[rnewman]

I think I just ran into another aspect. The code has:

         ; Omit AS in FROM, JOIN, etc. - Oracle doesn't allow it
         (if (= :select *clause*)
           " AS "
           " ")

Well, it seems like sqlite requires an AS where it isn't documented to require one: in a subquery :from with an alias. If I'm right (and I've sent an email to the sqlite mailing list to check), then this is a spot where Oracle requires one behavior and sqlite requires another, and there's no compromise.

That implies either hacking in a switch, or coming back to tackle this issue.

[rnewman]

Update: my bad; sqlite does not require AS unless the subquery alias is ambiguous. No conflict, then, just a preference!

[seancorfield]

Given HoneySQL's position of trying to be vendor-neutral and the fact that the three PRs referenced were all rejected due to that position, I'm closing this out.