Does untangled-datomic assume that all attributes belong to a certain entity? I’ve got some attributes that are shared globally and currently stored without a namespace. Is it expected in untangled-datomic that I would namespace these as well to take advantage of schema validations, etc?

An example of a global attribute would be :slug which is globally unique. The only thing I’ve come up with is to have a :meta namespace for these global kind of attributes, i.e. :meta/slug

@pithyless not too sure, based on what I can gather from the macros it appears your meta workaround is needed. @adambros may have another alternative

dont think i do, but if there’s a reason you dont want to namespace it you might be able to just hand roll your own schema entity by querying for it and seeing what gets put on it

I’m not married to the idea, I’m still working on how to best model the domain. But it feels like somewhere down the line it could be problematic not having a sane way to say: “this is just a datomic attribute that applies to many things, and not a ‘field’ on a specific ’thing’”. Just wanted to get some feedback if you perhaps considered this and rejected it as unnecessary.

you could write your own seed data just for those non-namespaced keywords

especially if there are only a couple — no reason you can’t use the standard datomic syntax

not sure about the reasoning behind untangled datomic’s design, why namespaces were considered to be required

if the issue is vtransact, you are correct that down the line you will probably have problems with it not wanting you to put :slug on anything

i do want to double check you are talking about vtransact

yep, I was thinking about vtransact and validations

yeah i see the problem now

you would have to put :foreign-attr on every namespace to allow it to have :slug

i think at this point @tony.kay might have something to say

i say this as im looking at one of our app's schema, and it seems like because we havent used vtransact, we havent ran into this yet

we are basically using artifact similarly to your proposed meta

is it a ref to an artifact?

i.e. [:todo/name “Bob" :todo/completed false :todo/artifact {:slug “a_slug”}]

ah no we have a ns for things like :artifact/title

but thats interesting

not sure if it fixes it for vtransact

artifact is a much better name; I might steal that :]

yeah np

so basically, you have datomic entities that have both e.g. :artifact/title and :upload/file and hence, based on the documentation in schema.clj`, are both kinds of “artifiacts” and “uploads”?

yes

Makes sense; I’ll try to go in this direction and see where I end up.

we would need to add some combination :definitive or :foreign-attrs to get this working right, but basically we arent using vtransact yet

Thanks for the feedback @adambros and @ethangracer. I’ll be sure to report back if I hit any major stumbling blocks.

@pithyless: FYI: vtransact is probably a dev-mode-only idea. It is not documented, and possibly even a bad idea (tm)

The Datomic idea, as you've found, is that there are no restrictions on entity content (attributes), though the namespace gives a hint.

same goes for entity refs, which I find a tad distasteful, since you're database can tend to get kinda warped...and my production experience with SQL causes me some discomfort with this

So, our extensions to schema in untangled-datomic are an attempt to give you tools for dealing with FK integrity and entity restrictions on wht attributes "belong"

Of course, they are advisory, and vtransact enforces them....but from a production viewpoint, you probably don't really want vtransact to "work" in production. This sounds counter-intuitive...but here's what's going to happen: 1. You implement your logic via vtransact 2. A bug happens 3. You hand-patch some data in the database (and screw up) 4. Production code now cannot proceed against that data (without further intervention) In other words, unless you can enforce the constraints everywhere, you end up with the possibility of failures in production caused by normal kinds of operational manipulation. One can of course, argue in a bunch of directions on this...I can make an equal case for wanting vtransact in production. Anyway, since vtransact requires discipline from developers, can be tripped up by things I've seen in most deployment operations, etc... I'm starting to lean to making vtransact be something that can fail hard in development mode (to keep you from writing code that corrupts your data model), but just logs warnings in production mode.

in all cases: consider our schema extensions EXPERIMENTAL. We are not yet decided on if/when we'll use them ourselves.

@tony.kay: Thanks for your input, that was very helpful. For now, I’m just playing with untangled on a side project, so I don’t mind backtracking once in a while. I’ve tried namespacing everything, per the schema extension approach, but I’m still not sold whether this is helpful for my use-case. I’ll definitely be playing more with this in the coming days.

Datomic tutorials are the best route for understanding how to structure the stuff.