Fork me on GitHub
Benjamin C03:04:18

I am curious if the all the database interaction in database_queries.clj from the rad demo is consolidated to make it easier to switch between datomic/sql/xtdb, (by adding aliases) or if it is a pattern that is followed in regular projects as well.


So here are some things to consider: 1. It is very hard to switch database once you’re in production. I’ve never seen anyone do it without a lot of pain. 2. Isolating yourself as much as possible from DB-specific code throughout your app does give you some measure of flexibility, but also costs something in terms of optimization. So, that said, I would not treat the “possible future move to a different database” as a primary design concern. It costs a lot to worry about, and is rare to actually do. In general your queries for reporting and such will be hand-written to the database in question, and there’s nothing to be done other than make it obvious where those are. That’s great as a pattern as the system gets larger, since you know where to look for things, and in theory could be a big help if you transitioned to a different storage system. The form/save-as-form function is written so that almost any write can be accomplished without having to talk about the database in service, since you basically are just sending in a normalized data map. So, I do try to construct all of my writes so that they use that mechanism. That gives you a lot of control over centralized security and other behaviors, and also makes it a matter of writing a compliant db plugin in order to port to an alternate storage solution. The former, for me, is way more important than the latter…but if you ever were forced to switch, you sure would be happy you’d done it.

Benjamin C18:04:40

Thank you! I appreciate the insight.

Jakub Holý (HolyJak)07:04:37

It might well be. I did follow it in b/c it seemed nice to separate the sql code from the higher-level code. Though in a bigger app I would likely split it by domain so I would end up with product/database_queries.clj , shopping_cart/database_queries.clj etc.

thanks2 1