Interesting! Are you using HoneySQL2 or anything[1]? I love the extras you added on top of XTDB; would definitely like to see anything clever you do with Postgres, since it seems every [large] project eventually uses an RDBMS for something, and I do not love them. 1. Toucan2 is probably too much baggage, with not enough community, but I recommend a look, for inspiration

I'm not using any sql wrapper libs--just next.jdbc and this snippet linked here for migrations: https://clojureverse.org/t/how-do-you-do-database-migration-evolution/2005/2 of course once you've got postgres set up and working with this howto guide, you can always add on honeysql or anything else

I am using honey; that's the bare minimum wrapper I'd want, personally, having dealt with lots of code that built sql from strings. Honey2 is not bad at all, though I need to take the time to understand some of it better. I'm not really migrating; xtdb will remain my single-source-of-truth, and place-from-which-i-can-rebuild-all-the-other-dbs (well, coupled with a growing collection of .csv files). Postgres just turned out to be a convenient way of serializing certain things, maintaining some constraints, and doing a handful of monster queries on slowly-changing data. I'm doing semantic search too, with typesense for text-only, and qdrant for image and multi-modal; also pre-creating sqlite db files for inclusion in my flutter client's bundled assets. I have so many little biff-compatible shims for libraries, databases, and services I've tried out; not enough time in the day to release them all as little libraries. I'm thinking about adopting Polylith before too long; I know it probably seems antithetical to the not too too simple philosophy of Biff, but if I were to share all my bits and bobs, I think a polylith monorepo, with a biff 'base' would make a lot of sense.

I am really enjoying xtdb and don't have plans to use this, but I really approve the direction. Having two high powered databases side by side will be good for biff.

sounds like you're doing a lot of fancy stuff 🙂 I'd be interested to see/read about your take on polylith; I've looked into it briefly but don't really grok it. I have been thinking of experimenting with Pathom--probably would never include it by default in Biff but I think it'd make a good addition for a lot of projects as they grow

I find the pathom value prop quite convincing, but only for larger projects than the ones I can handle 🙂

yeah--I was originally wary of pathom since it felt like just another layer that I didn't really need. And I've only got one database anyway; I don't have a bunch of microservices or something that I want to create a unified query API for. However I've since realized that any logic you write on top of the raw data (e.g. "is this advertisement currently eligible to be shown in the timeline?") is another "data source" that can be useful to have unified with the DB. especially since you get some dependency injection benefits as well; your additional logic/derived data functions can specify what data they need and the caller doesn't have to worry about if it has all the right inputs and in the correct shape. yakread and the sample both feel like they're at the point where they'd benefit from that

Oh, I started making something like this yesterday! Glad that I came here to check if something was going on 😆

yeah, should be fine. github doesn't seem to show me the entire commit history on mobile, but from what I did see it didn't look like there were any changes that would mess up biff

ok thanks

instead of biff/system try main/system, where main is your main ns

https://github.com/jacobobryant/biff/commit/9bcd6723bd70289054d7a6a6854b15ce6e2747bc

also that should only be used in the repl.clj file. in other places the system map will be passed in as a parameter