For Cloud, there seems to be a limit of 4096 characters: https://docs.datomic.com/cloud/schema/schema-reference.html On-prem doesn’t seem to have this limitation.

Thanks @U06B8J0AJ! Indeed we have on-prem -- I am guessing it's the size of a sql blob. If someone confirms would be awesome 🙂

(d/db conn) using the peer lib

I think he is asking the other way around.

yep, my bad

(let [db  (d/db conn)]
    (d/connect  (:id db)))

apparently (:id db) gets the uri

undocumented, though afaik

I already made a big data product with datomic (with on-prem) I received some GB of CSV files + a running SQL database, then I made a pipe to transact this data into a temporary DB-URI Once I finish this "raw" import, I made some queries in this db and insert "real" db-uri, that is used my the application This "real" db-uri goes huge very quickly, then monthly I create a new one, then the aplication sometimes need's to query the current + all olders db. A possible optimization is use CSV+SQL+Olders db's to create the "current" db.

Huh, fascinating. It might take me a while to fully parse that, but I'm pretty sure that sounds like what I had in mind. Hmm. I think what I would do is possible use an sns event to trigger a transform on s3 raw log files. It would reformat them to something that could be ingested by datomic?

But either way, the basic idea is to have a datomic view of imported raw files

No. List items are data, not schema. Your schema should define something like :todo/name as a string and when an admin adds another item, transact {:todo/name <another item>}.

Ok, thanks, that makes sense. So list items would be an entity with a :todo/name as a string and a :todo/completed as bool, and todo list could be another entity that had a list item as an attribute with cardinality many, so that, given a todo-list, I could pull all its items. I could also imagine doing a full text search of all todo’s and wanting to know to which list a given result belonged; do I also need to include an attribute on the list item with cardinality one that points to which list it belongs to?

Back references are just as fast as forward references. If you're querying, just ask [?list :list/todo ?todo]. With that in mind, if you want the constraint that each todo is a member of only one list, I would instead have a cardinality one reference on the todo (`:todo/list`) and query for all todos pointing to a given list when you need it. If you're pulling, you can back-reference by saying (pull db [:list/name {:todo/_list [:todo/name :todo/completed]}] <list id>). Lookup :as in the pull docs if you want to rename the back-ref. Are you planning on resetting the completed bools daily?