Fork me on GitHub
Drew Verlee00:02:23

@seancorfield can you briefly describe those two camps?

Drew Verlee00:02:16

Anyone know if you can pick a table inside the same sql query? like given a column with a table name, insert into that table? i dont see why not… but i have been suprised before.


@drewverlee In general, your architectural model is likely to have richer types than can be represented in a SQL database. In Clojure, you may have keyword data, sets, vectors, objects (records, UUIDs, for example) but none of those exist in SQL directly so you have to have some sort of mapping to/from SQL types in order to accommodate that -- and your mapping is usually going to be specific to your business model's needs (including if and/or how to handle data coming back from the DB that no longer maps to your model -- which may or may not be possible depending on your situation).


Having your database as your architectural model is artificially limiting, and forces you into a strict relational model. In the OOP world, it's the sort of thing that causes implementation details to leak into your model as well as leading folks down the "anemic domain model" path. In the FP world, you are saved from some of that but you still end up with a lack of abstraction -- or a very leaky abstraction! -- which can hamstring your attempts to evolve your business model or lead to "non-idiomatic" data manipulation code in your business model.


It's instructive to read some of the experience reports from the Agile world where several of the "Big Names" in that field have deferred the choice of database as long as possible so that they can focus on the business model (and iterate over that) without being locked into a representational state -- and in some cases ended up with production systems that use simple files for persistent storage instead of a database anyway!

Drew Verlee02:02:09

@seancorfield I hear what your saying, but i’m having trouble envisioning the specifics of the alliterative. I think the limiting factor for relational dbs isn’t the types we have available. But how * hard it is to change the model when your not the db dungeon master. * understanding what that hell that datat represents in your business domain I think there are some technical solutions to the first one that take advantage of immutability and how fast computers are these days. I think it might be viable to try to capture all data possible with just attributes into kafka and have onyx sort out what you need without having to come up with a “schema”. The second one is harder and is more about having people that understand the business domain, vision, etc… I think we underestimate how many bugs are due to essentially mis-understanding the domain. e.g how can i think about edge cases to a problem i dont really understand?


@drewverlee Have you looked at Datomic?


(and, in particular, have you looked at what you get inside an RDBMS if you use it as a backing store for Datomic?)


Datomic is a very clear example of how you separate "storage" and "model". You have a schema, but the actual stored data looks nothing like that model, not in the datoms themselves, nor in the representation Datomic uses in whatever backing storage system it is using.


@drewverlee: Bobby Calderwood did a great talk that seems pretty related to your thoughts about kafka - I haven't watched it for a while so it may not be exactly along the same lines, but I think it's pretty close.

Drew Verlee16:02:59

I got the idea from his talk and Martin's work


Ahh cool, that's probably why it reminded me of it


has anyone had experience defined specql queries through the mount lifecycle (i.e. if you have a db connection that's only started on mount start, and then secql define-tables that references that db connection)?


mount's working theory is that things like DB connections are runtime controlled, stateful things; based off reading the specql documentation, it assumes that a DB connection is just part of your code (presumably stored in some local global), and needs to be available at compile time. You can probably get these to work together if you try hard enough...but probably with a lot of headache, since they seem to have 2 very different philosophies about dependencies on things outside of your codebase


but...I've never heard of specql before now, and this is just the impression that I get from reading it's docs right now, so easily could be wrong


indeed.. you're right. Took a while to figure it out since specql attempts to define queries at compile time. But managed to get it working (for now at least):