good question, I never done that
(d/transact conn
[[:db/retractAttribute [:db/ident :business/email] :db/unique]])Relaxing constraints like this should be fine, Adding them would be a problem, unless you can ensure they hold at transaction for the existing data already.
if I already have an existing connection pool for a JDBC database, can I have datahike-jdbc reuse that? it looks from the konserve-jdbc code that it's expecting to manage the connection pool and so on by itself, and can't accept an already-constructed javax.sql.DataSource.
I've already got a SQL database in use by this app, and I'd like to let Datahike create its table within my existing schema, and use Datahike and the vanilla SQL side by side.
We could change the multimethod dispatch in Datahike, ideally without breaking current users configs. I have not used derived keywords yet, do you think it would be difficult to add?
I think I can just add a connection object to konserve and we should be good to go. That's how we pass data to c3p0
okay, I managed to hack this together with some defmethods and a small patch to konserve-jdbc to make get-connection a multimethod.
so now I have a :backend ::mydb that forwards pretty much everything to :jdbc, but overrides datahike.store/store-identity to be meaningful in my context, and of course konserve-jdbc.core/get-connection to return a connection from my pool. I can send a PR for that, once I'm finished messing around and I'm sure this all works.
Cool @braden.shepherdson! @alekcz360 can we generalize/integrate this in konserve-jdbc?
Yeah. @braden.shepherdson tag me in it I'll do the review and merge
good stuff, I'll aim get this posted today.
it's a bit unfortunate that the multimethods in konserve(-jdbc) and datahike(-jdbc) that are keyed by :backend have non-namespaced keywords and no custom hierarchy.
that means I can't do (derive ::mydb :jdbc) and inherit the :jdbc implementations, except for the one or two methods I actually need to override.