Fork me on GitHub

A fairly common occurrence with Datomic Cloud is,

" Connection reset by peer"
This is when waking an HTTP endpoint during a cold start. A second request returns normally. I saw this with Solo, and now it's presention on Production as well. Something seems to be getting ahead of itself. Has anyone seen this? I'm struggling to find anything in CloudWatch that indicates an error.


@U06B8J0AJ according to a ticket i opened in December, Cognitect knows about the problem and they're working on a release to prevent it from happening. in the mean time they recommend implementing retry logic in your code.

👍 1

I love the idea of Lambdas, but a way to get around it sounds great right about now.


for sure. we eventually implemented retry logic, but it felt a little dirty to commit extra code to handle a predictable downtime after each deployment. deploying Ions behind AWS API Gateway is part of the official Ions tutorial.


we wanted zero downtime deployment and instead we got one guaranteed to happen 😉


(but we love Ions and Datomic so our brand loyalty won in the end)


Yeah, for what it's worth, the issues with hooking up lambdas in this affects everyone who tries it, not just Cognitect. As far as AWS goes though, it's a bit disappointing that they still haven't solved some of the basic issues with lambdas, given how they want to position them as glue between all their services.


is there a safe/sane way to bump the sync-libs 120 second timeout when deploying to ions?

Laurence Chen13:02:57

Hi, I have certain question with datomic.query.EntityMap. I posted my question in stackoverflow. Any hints will be appreciated.


d/touch is not invloved. You can simply reproduce with (seq (d/entity (db) 1)). I'm not sure of the rationale to not return the special :db/id attribute when "seqing" an entity. My guess is that the semantics of the operation is to just return all the attributes defined on the entity, excluding the special attribute :db/id and all reversed attributes.


Has anyone used something like datomic.api/filter to implement access control? I.e., is there a straightforward way to create a view of the database that only contains what a user has access to see?


Yes, it has been done


That is the most straightforward way available. Because it runs your predicate once per datom make sure that predicate is fast


I'm not in this situation but how do you document your entities if you reach for example 400 attributes? ex: what attributes belong to what entities, namespace prefixs are not enough since a single entity can have many (belong to more than one group of related attributes). do you write a function to check/validate each new entity? seems like sql is a win in that you have a central point that explicitly documents this part.


With that many attributes, you likely need a proper documentation process in place. Since Datomic attributes are themselves entities, you can define your own Datomic attributes and organize all your attributes however you want to support your documentation needs. You can also define specs for each set of namespaced attributes and s/merge them to validate your entities.


if your entities are "typed", you can add a simple meta-schema to your schema


:entity/type ref to an entity-type entity which has e.g. :entity.schema/required-attrs (ref to attribute entities) :entity.schema/optional-attrs (ref to attrs also) and documentation (:db/doc)


:entity/type could even be cardinality-many, giving you something trait-like


guess, there are many ways about going with this, both your ways are valid, another way could be to just always prefix all attributes an entity might have with the same namespace and use references, but this increases the number of attributes.


On the other hand, tables gives you all this work for free (at maybe a cost in other parts)


hi, will Datomic ever support :db.type/vector ?


stay tuned 😄

😯 10
Mark Addleman18:02:59

This is exciting!


:db.type/edn 🙏

🙏 1