hey all, newbie question regarding the pull api. when resolving a ref entity in the pull api, the value returned is a map of attributes (e.g. pull [*] -> {:my-ref-attribute {:db/id 12345} ...}, pull [* {:my-ref-attribute [*]}] -> {:my-ref-attribute {:db/id 12345 :db/ident :my-ns/my-ident} ...}). when resolving a ref entity in the query api, the actual ident is returned. (e.g. find ?eid ?my-ref-attribute -> [12345 :my-ns/my-ident]). is there any way to return the actual ident for a ref from a pull (as in the query api), as opposed to a map of attributes? so the return value would be {:my-ref-attribute :my-ns/my-ident}. this thread – https://groups.google.com/forum/#!topic/datomic/xxoYiko2muY – on the datomic user mailing list gets at what I’m trying to do. just wanted to check if that’s still something unsupported by the api thanks for any input or advice!

do people usually default to include project names in their :db/ident keywords? for example, do you use :myapp.user/first-name or just :user/first-name

@mss The query api does not automatically change ids to idents. I am not sure how you got that impression

@mss The only api that has the behavior you describe is the entity api.

you’re right, my mistake. meant to say that there’s an easy syntax for specifying how to return an ident

and what shape to return it in

pull can return an ident easily, but it’s always in a map of attrs

afaict

in a query you need to explicitly follow :db/ident to the ident

the only api that implicitly treats entities-with-idents as keywords is the entity api

in every other case, if you want an ident you need to ask for it

with pull results, a common strategy is to walk the results with clojure.walk/prewalk and replace any maps with :db/ident in them with the ident itself

then ensure you pull :db/ident in your pull pattern

pull [* {:my-ref-attribute [:db/ident]}] in your example

makes sense, really appreciate the help

I'm a bit confused about datomic starter and free. (I'm developing an app for a small ngo, so the pro version is certainly a no-go due to the pricing. small ngo's can't afford it). I do understand the Client not available on the free version and limited to 2 peers etc. But, it's about the updates: the free version can be updated at any time (meaning: install a new version and start using it), while using the starter version, this is not possible? Am I right?

i believe starter is free upgrades for a year but then you need to pay. not sure if you get a perpetual license for the latest version at the end of that year but it seems that way

So, free is unlimited updates, starter only for 1 year and than you need to upgrade to pro to receive updates... Too bad.

@kurt-o-sys @spieden starter has perpetual licensing so you can continue using versions released prior to the expiration of your starter license indefinitely.

@jaret Right, but no updates, meaning, after a few years, you'll probably lacking some features/security updates/ ... . Not a good idea, experience tells me.

Yeah, thankfully for any reasonably sized money making enterprise the license cost is pretty affordable

right... that's it: > any reasonably sized money making enterprise the license cost is pretty affordable I'm talking about small non-profit organizations/associations, working with 1-3 FTE and a lot of volunteers (from 30 to >100). It's really not affordable for them. They are financially very small, but they are not small at all in terms of tech needs. Their 'business' is often pretty complex compared to usual businesses and they need to fall-back to poorer tech, which isn't really helping them either. (Yes, I know, the free edition, but in this use case, the client library makes much more sense.)

@kurt-o-sys maybe talk to them and they’ll cut you a deal(?)

cognitect that is

A late thank you for the discussion about enforcing constraints in transactions. I'm not sure what the practical conclusion might be, and my question was for the sake of understanding, not a particular use case.

I can't help but wonder though, how people make sure their data doesn't get corrupt, when constraints are expected in the data. I guess only smart and proactive testing might allow smooth sailing....

But the cost of an error would be eternally corrupt data, given the write-only nature of datomic, which is a bit more than with an RDBMS, where the cost of an error is more transient (in the non-pathological case). Just a thought.

@matan Hi! There was a discussion on precisely this topic yesterday (or the day before yesterday?) on this channel

The gist of it was that you cannot enforce constraints directly. If enforcing them in your application code is not enough, you can enforce them in a “transaction function” which runs on the transactor, but this relies on your application code using that transaction function (it could bypass it)

Another approah could be to either inspect backups or inspect the transaction log live on the lookout for constraint violations

(e.g. run a dedicated process to do this check)

Yes, I know, I skimmed the discussion

Errors would then be reported back to you, and you can fix them

It just seems that's a soft spot as is

Hopefully shouldn’t happen too often unless a big error was made in production code

It’s not quite right that the data would get eternally corrupted though

oh?

you can always excise data, commit a transaction which fixes the issue, or in extreme scenarios I guess you could even re-build your whole database

if the data corruption is really too nasty

We are talking disaster recovery here, not routine operation

seems to boil down to exceptionally judicious testing

but for example, say you are doing daily backups

and you realise that an event has occured today which has corrupted your data in a non-fixable way

you could restore to yesterday’s backup, then apply every transaction that was ran before yesterday and today

fltering out the transactions that caused the data corruption

or something like that

any good book covering such processes? not that online docs aren't good enough...

You’ll have to wait for someone else’s answer, I just started learning about Datomic

But the online doc does talk about the “Log API”

which could be used in conjunction with backups to do this kind of recovery

Are you worried about a particular kind of data corruption?

Not really, I was just assessing the pros and cons of using datomic

Do you have a kind of constraint in mind that would be enforced by a relational DB and, if not enforced, would lead to “unrecoverable” data corruption?

By the way, in clojure core, we do have validators built-in to the api, for the state handling constructs (atoms, agents...) I wonder why this concept was not carried over to the flagship database being datomic

@matan unrelated but if you are assessing datomic, check this out: https://medium.com/@val.vvalval/what-datomic-brings-to-businesses-e2238a568e1c

Mmh, I would be curious to hear about that too

Well, maybe someone will chime in ..

Calling it a day