Fork me on GitHub

assuming i have a database value which has a certain entity id present within it, and i then use (as-of db some-point-in-time-before-that-entity-id exists) , and I do (d/with ...) on that as-of db, with a tx like [:db/add entity-id some-attr some-value], why does that succeed still? surely it should blow up with an invalid entity-id , since it technically doesn't exist at that point in time?


man, it's so tempting to start using Datomic for a project I'm working on right now, because I saw the video about resource ownership/authorization, and it just felt so elegant to solve it that way (transform the database object into a new database that only contains objects that are "owner" by the current user)


but I feel like it would introduce so much complexity at the same time


@greywolve: weird indeed, are you positive about the entity id not existing before that ?


@lmergen: what complexity are you worried about ?


operational complexity


i see that i need to maintain & operate several services


right now we do $everything in AWS and the ecosystem it provides


biggest impediment is the limit on the number of processes IMO


I do deploy it on AWS, and it's OK operations-wise


and we're only a 2-devs startup


but you do have to plan and accomodate for it


but it seriously goes against my gut feeling right now... it's a beautiful thing, but it would be awesome if there would be some datomic-as-a-service with AWS or so


val_waeselynck: yeah i set the entity id to about 2 years back, so pretty sure 😛 when i restore the entire db back to a point in time just before that entity existed, then d/with correctly blows up when i try that tx


then I would be using it without even thinking about it


apps + 2 transactors + ddb


also, i wonder how well Datomic scales on a write level


it’s not that big of an issue. there are details, but it’s not rocket surgery simple_smile


@lmergen: official stance on this is that your write volume must be consistent with the upper limit on your database size (10 billion datoms)


oh then that's not going to work anyway... shite


@lmergen: having said that, it can be interesting to use a hybrid architecture with some NoSQL database for collecting most of your data and Datomic to post-process it


the thing is


we have a huge data warehouse (think 10 billion records / month)


and we have some relational database


and I'm trying to find a solution to query our data warehouse, mix & match it with our relational database, and not having to worry about the slow query time of our data warehouse


in other words, i want magic!


and it needs to scale up to the moon too simple_smile


worrying about running two transactors is the least of your problems, then simple_smile


yeah, I'm trying to explore whether Datomic is a solution for this


someone suggested me into this direction, to "pre-warm" the pipelines with our data warehouse data...


but I don't think it will work


I'm not an expert in this kind of deployment 😕 maybe you shoud just contact the guys at Cognitect


yeah I'm already in contact with one of their sales people, but I think what I'm after is actually some consultancy on this matter.. hmm


well if anyone is reading this, and thinks they can help us with this, send me a pm


I think Datomic aims to fulfill the role of a traditional relational database — with better scaling characteristics than most SQL's — more than the role of a "big data" solution.


@lmergen yeah, Datomic is not a solution to this problem, it plays in the oltp space. Likely in your situation your sql database will need to be able to utilize pre-calculated historical aggregations done on warehouse data, in the appropriate shapes, so that you can use sql across both datasets. In the warehouse/sql world this is an ETL problem, one needs to orchestrate pushes from the warehouse into some version (slave/standby/replica) of the oltp system. This usually is very messy and complicated. What's appealing about Datomic from an architectural perspective is being able to look at this problem from a pull perspective, with layers of declaratively-defined caches


yep, this is exactly the path we're going to be taking


as in, I don't think it's possible to do this in realtime, we simply need to schedule periodical jobs


people are doing all sorts of fancy stuff to make results appear faster, e.g., but all of this brings huge amounts of complexity


@greywolve: branching off of an as-of point with with isn’t supported.


with works against the db without the filter. as-of dbs will filter out prospective transactions from with when queried against. At present, prospective branching from points in the past isn’t supported.


bkamphaus: thanks for the clarification simple_smile


Hi all, I’ve been examining the schema of a Datomic database, using this kind of query:

  (d/q '[:find ?attr
         [_ :db.install/attribute ?e]
         [?e :db/ident ?attr]]
But I get retracted attributes as well. Does anyone know how to filter out retracted attributes?


what makes you think you are getting back retracted attributes?


I’m getting back attributes like



I’ve inherited this code, with no handover, so there’s a possibility that’s this is some non standard craziness and I just haven’t found the place where it comes from.


@arthur.boyer: You can’t retract attributes. That looks like renaming (with a retracted+sha convention) only, and renaming is a typical way to deprecate an attribute. In general, retracted values will only appear in history databases, and you have to bind the fifth position of the datom (the ?added) portion to see if it was an add or retract op.


Ok that makes sense. I’ve run queries binding the fifth position and they came back true. I’ll do some more digging and see if there’s a way I can clean them up. Thanks.


if you don’t want those values returned by a schema check, I guess a regex against string rep of the ident would be fine (assuming those are only cases of “retracted”)


That’s what I’ve been doing, but it feels like a nasty hack, and not what I think idiomatic datomic should look like.


So, what do you do if you do want to retract an attribute? Do you retract all the datoms that use it?


hey all, I have a question on the pull syntax bnf grammar (copied from the pull api site):

pattern            = [attr-spec+]
attr-spec          = attr-name | wildcard | map-spec | attr-expr
attr-name          = an edn keyword that names an attr
wildcard           = "*" or '*'
map-spec           = { ((attr-name | limit-expr) (pattern | recursion-limit))+ }
attr-expr          = limit-expr | default-expr
limit-expr         = [("limit" | 'limit') attr-name (positive-number | nil)]
default-expr       = [("default" | 'default') attr-name any-value]
recursion-limit    = positive-number | '...'
I just tried putting a default-expr in as the first item in a map-spec and it worked. so i’m thinking the doc on the site is incomplete? or am I missing something?


a more common pattern is to migrate data to a new Datomic database (by i.e. replaying the log with filter/transform) with a finalized schema. That works if you want to drop a lot of the initial modeling learning process, say. But I think the possibility of retracting attributes could introduce more operational complexity than keeping them and removing them from queries.


@ethangracer: do you have a repro or just a code example of the specific expression that works and violates the grammar? I can take the repro case to the team and see whether the grammar or the behavior is correct.


@bkamphaus: Thanks for that, I think the practical upshot now is that I can safely ignore things named retracted and we can consider a more radical solution later.


@bkamphaus: sure, for this sample the idea is that I want to load todos from the server. but maybe I haven't sent any todos to the server yet. In which case I want to return an empty vector (to distinguish between loaded / not loaded from the server). So the bnf compatible query is

(d/pull db [{:todos [:id :title :is-completed]}] __id-for-todo-list__)
which returns nil if that todo-list has no todos. If instead, I write:
(d/pull db [{(default :todos []) [:id :title :is-completed]}] __id-for-todo-list__)
then the pull returns [], even though this is not documented by the bnf


@ethangracer: thanks, I’ll investigate and get back to you.


@bkamphaus: sounds good, thanks