Hi, thanks a lot for creating Datomic Local. Any chance to also activate datomic.api for it? Background: we are considering moving in this direction:
It would be great to use Datomic Local instead of Sqlite.
Thanks for the feature suggestion. Could you help me understand what features would be most useful from the peer api on dev local? I am not trying to pre-load your answer, but I have heard from many customers the desire for the entity api. But specifically with the approach of small embedded storages, I am interested if there are other apis in peer that are crucial. For example, I am not sure sync-excise is necessary at this local scale, and if we should support excision at all, but perhaps it is important for you considering GDPR and operating with this model.
A specific list of desired apis would be extremely helpful or just a general report of what you feel you are missing with only client in local.
Cheers!
-Jaret
Hi Jaret,
Thanks a lot for your answer. I hope you are doing well. Most of our app is deeply entangled with datomic.api and the entity API. Sure, we could spend a lot of time and effort to migrate everything to datomic.client.api. The more significant issue is that we will likely introduce many new bugs. The usage of the entity API is tricky to detect since the entity object might be passed from a function in another namespace. In contrast, the current namespace might not even depend on datomic.api. Finding out what attributes to pull to replace the entity with a map is also a source of error.
So, in general, complete compatibility with datomic.api would be desirable. Our system, for example, also depends on tx-report-queue a lot. But I can imagine that features like excision yield a lot of implementation effort. We never needed sync-excise yet. I guess that you can go without the excision if each customer has their own database. Since storage is cheap, you could delay the deletion until the customer cancels their SaaS subscription. I’m no GDPR expert, and I don’t know if that would be ‘compliant’. But at least it would offer the possibility to delete all the data of a customer physically.
Best regards,
Max
I probably can just use the embedded storage (datomic:dev://) to realize a system where each customer runs on its own server (or rather container) and have its own database? For disaster recovery, I can do a Datomic backup every hour.
We use the embedded storage for our local development environment. I didn’t come across anything that is not supported with the embedded storage. Or did I miss something?
Having Datomic Local support the datomic.api would be beneficial to avoid having a second JVM. Doing a live backup of the segment files would probably also be more straightforward than doing a live backup of the H2 db.
Best regards,
Max
1 Like
One thing I forgot is that Datomic Local includes the Datomic client API, while the other variant with the embedded storage would require to spin up an additional Datomic peer server to be able to use the client API.
1 Like