First of all, thank you @quoll for writing such superb documentation (the github wiki)! Very helpful for a beginner. I'm investigating using Asami for a web app. Thinking of the data model as a tree of nested ordered lists would be close enough. Here are some questions: 1. I'm thinking of making use of Asami's ability to have arrays as attribute values to solve the ordering issue: each list item would have an array of sub-list items, etc. I've seen how to append this array, but I'm wondering how I would accomplish re-ordering it? Transact a new array with correct order? 2. Another reason to look into Asami has been the option to persist the data to disk. Ideally, the app would load data to in-memory Asami from on-disk Asami on startup, and store the changes back to the disk on closing the app. Is this feasible, or is it too complicated and I should just use the on-disk version all the time? 3. Views of the app would amount to displaying a subtree. I've found Datomic's pull API useful for retrieving the whole subtree in a single 'query' and rendering the UI from that. Am I right in thinking I could accomplish the same thing with Asami's query? Thanks for your time!

I don’t know that I have great answers here, but I’ll try: > I’m thinking of making use of Asami’s ability to have arrays as attribute values to solve the ordering issue: each list item would have an array of sub-list items, etc. I’ve seen how to append this array, but I’m wondering how I would accomplish re-ordering it? Transact a new array with correct order? Transacting a new array is how I’ve done it before. I’ve considered trying to diff between arrays, and then doing: • prepend operations • concat operations • insert operations The first 2 of these are trivial, and insertion isn’t difficult either. But it’s identifying that delta that’s tricky, especially when there are multiple operations, and could also be costly if there are complex elements in the array. So I just made entity updates follow the general approach of throwing away the existing list and creating a new one. So yes, “Transact a new array with correct order” is how I do it. If this proves tedious, then it’s always possible to manage updates manually.

> 2. Another reason to look into Asami has been the option to persist the data to disk. Ideally, the app would load data to in-memory Asami from on-disk Asami on startup, and store the changes back to the disk on closing the app. Is this feasible, or is it too complicated and I should just use the on-disk version all the time? You can do this, but it sounds like more work that you need. Is there a reason to avoid having it on disk? If you move the data between databases like this then you’ll lose the history, and you’re wearing the cost of indexing it as you write to disk. If I were sending it to disk, I would just use (spit "filename.dat" (export-str (db connection))). When you load it again, you’d use (import-data connection (slurp "filename.dat"))

> 3. Views of the app would amount to displaying a subtree. I’ve found Datomic’s pull API useful for retrieving the whole subtree in a single ‘query’ and rendering the UI from that. Am I right in thinking I could accomplish the same thing with Asami’s query? I haven’t spent much time with the “Pull API”, but to me it always looked like it was doing a conversion of your structure into a standard query, and then doing transforms on the results. So, yes

Sorry to take so long to respond @mithrandir03. You sent your message just as I was going out