Or should I use enums for this, an enum for each property ? Other properties are for example game-speed, window resolution, etc.

120 (or even thousands) doesn’t sound like very much… you could keep it in a single .edn file

I also thought about that, using only a single file might make things easier too

Setting up datomic (or any db) might be useful in the long term but if you are still prototyping and figuring things out, it might not be worth it in the beginning.

cool project btw, exciting to see games made in clojure

there’s also datalevin (which doesn’t have temporal capabilities) but uses LMDB which might be better suited for embedding in a game

In what ways would it be useful? I mostly think about organizing the data properly

It would also give me undo/redo capabilities

also a datalog query language allows you to ask questions about the data in a more convenient way

Although I would lose the git tracking of properties

But just for curiosity, how would I define these one-off properties ? As enums or with a unique id key ?

it works:

(def rec-rule '[[(rowns ?e ?user-id)
                 [?e :permission/owner-id ?u]
                 [?u :user/id ?user-id]]
                [(rowns ?e ?user-id)
                 [?e :parent/id ?p]
                 (rowns ?p ?user-id)]])

thank you

i skimmed through everything, maybe i missed it, what is your guidance for seeing the present state the schema , like today i have directory filled with EDN files, roughly each entity type gets its own EDN file, and if i want to add a new attribute i append to that file. In this setup would you recommend i look at the base EDN then each schema migration searching for any additional attributes on the entity type ? or ?

For retrofitting into an existing project, caribou can simply take over new migrations using epoch zero. I don’t think there is a good way to get caribou to “incorporate” your existing schema other than tedious translation of entity zero to corresponding transaction(s). Then, you will be faced with a second challenge: can you re-transact your schema using caribou without consequence? I don’t think it can be done. Shooting from the hip, there is still hope in this kind of approach: Build up your existing schema into caribou-compatible migrations as epoch zero. Then create new migrations in epoch one. For testing, have caribou migrate epoch zero then epoch one. For “production”, only migrate epoch one. The epoch numbers are arbitrary so you could make the existing state be epoch -1 and the new stuff epoch zero (the default) as a kind of safety mechanism.

Actually, if you are adventurous, you could “fake” a caribou migration that includes your existing (forensically constructed) schema. Then you could keep everything in epoch zero and have the best experience for testing and documentation and such. I didn’t foresee this requirement but it would not be hard to generate a fake migration.

hm i’ll have to play around , to see, our current schema can’t be transacted in 1 transaction either

because we register some idents and use them later on, they need to be separate

That’s not a problem for this approach: you could fake N migrations. The key is to get them into a source file that can then be hashed correctly.

so your entire schema and it’s full history is in a single EDN file ?

namely the migration EDN

Not necessarily. I use aero to split it up into separate EDN files. And, on top of that, you can generate the tx-data with tx-data-fn to get the data out of any EDN or non-EDN file if you want.

hm ok , we have a lot of schema so i’ll need to do something modular

Caribou doesn’t care about where you source the data. You could put the whole thing in a .clj file, but I think that defeats the documentation and migrations-as-values concept.

A mix (using tx-data-fn and/or aero) is a good compromise. The key is that wherever it comes from, it must yield immutable tx-data.

(except step-fn)

right, i’m definitely pro data/EDN

I’ll make a note to update the README since, in hindsight, bootstrapping into an existing dn is likely to be a common request.

I just pushed a commit that adds support for “adopting” an existing database via the claim! function. The README has been guidance on how to adopt an existing database.

that was fast 🙌

Seems to be some overlap with conformity? https://github.com/avescodes/conformity what would you say is the most important difference?

Doesn’t require a transaction fn (only the built-in cas). Works with Cloud. Considers migrations as a dependency graph (allowing for concurrent development) versus a linear sequence. But there is no doubt the two are in the same space.

This looks cool! Thanks for releasing it

I wish this was here 3 years ago. 🙂 Thanks for the release!

LOL … I very nearly released it two and a half years ago, but my OSS career got sidetracked by employment where Datomic was not in the picture.

in Hungary swallows, storks, wild goose and crows are the most well-known migratory animals, so i might have named named a library accordingly 🙂

> allowing for concurrent development what does that mean more specifically? different code branches can have different graphs?

Yes, branches is a good example. Branch A only needs migration A and its dependencies X, Y & Z. Branch B only needs migration B and its dependencies X, Y & Z. Either branch’s migrations could be applied to a shared dev database first. Either branch’s migrations could appear first in the EDN file defining all migrations (facilitating merges) and either branch could be deployed before the other, regardless of the order in which it appears in the EDN file. Another more extreme example is a set of apps that share a production database. A shared EDN file could describe common migrations and individual EDN files could hold the app-specific migrations.

This info seems README.md-worthy!