This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (10)
- # boot (15)
- # cider (9)
- # clara (195)
- # cljsrn (24)
- # clojars (20)
- # clojure (46)
- # clojure-android (1)
- # clojure-germany (15)
- # clojure-greece (16)
- # clojure-nl (1)
- # clojure-russia (13)
- # clojure-spec (28)
- # clojure-uk (44)
- # clojurescript (104)
- # clojurex (1)
- # component (7)
- # css (2)
- # cursive (27)
- # datomic (92)
- # dirac (12)
- # emacs (5)
- # lambdaisland (3)
- # lein-figwheel (36)
- # mount (87)
- # off-topic (8)
- # om (102)
- # om-next (3)
- # onyx (30)
- # pedestal (3)
- # re-frame (26)
- # reagent (20)
- # robots (4)
- # specter (18)
- # spirituality-ethics (1)
- # untangled (127)
- # yada (11)
is it right that attributes are idents and therefore are stored in memory in every peer? is this why the recommended limit is 1000000?
Reading the docs a bit more, it's a bit more clear: Idents should be used for two purposes: to name schema entities and to implement enumerated tags.
What I'm calling an attribute is actually an ident to a schema entity (attribute)
I wonder if you can create schema entities which don't have an ident and refer to them by id
@danielstockton: the ident is a required element of a schema entity (attrib definition): http://docs.datomic.com/schema.html#required-schema-attributes
i'm trying to get my head around the point of installing an attribute and why this is useful i understand why a schema entity must have particular attributes but not this one: :db.install/_attribute :db.part/db
@danielstockton: Not an expert, but there is also
:db.alter/_attribute so it doesn't have to be
im just wondering if there is any leverage to be had from this or its just an implementation detail
@danielstockton: not an expert, but as I understand it the purpose of
:db.install/_attribute is to hook the schema entity to the db entity. Otherwise the database doesn't know about it (and can't use/enforce it).
Does anybody know of good resources about running multiple datomic instances on the same backing storage? we're trying to work out what the best practice is around this sort of thing
The tempid is intended to be opaque, so no inference about partition should be made from it. Implementation-wise, the transactor could presumably infer the partition, but it can't infer that the entity you're creating is intended to be a schema entity that should be used to define legal attributes.
:db.install/_attribute is an inverse, so the schema entity doesn't have the partition as an attribute; the db partition entity has the schema entity as an attribute.)
that's another thing i don't understand, i thought refs were in both directions
i guess you have to state a direction so datomic knows which one to use actually
they're traversable in either direction b/c of the indexes, but you still have to pick which entity has the attribute.
so when you want to transact a new attribute on to an entity in a certain partition, i guess datomic looks up whether this is a valid attribute for that partition
still seems like it would be possible to infer this information throug the tempid and if :db/cardinality is present
it's not being installed in the partition, it's installed as an attribute of the db partition, which is special.
(that may not be really accurate, implementation-wise, but the idea is roughly the same. you're telling the db to use this entity as a schema entity; it's very different from just transacting an entity into a partition.)
:db/cardinality is a reserved attribute, it could tell the transactor that 'this is a schema entity'
very extremely inappropriately coarse analogy to SQL: DDL does different things than DML.
there has clearly been some effort to define everything using the same data model
there's nothing stopping you from writing
transact-schema that adds the
:db.install attribute for you
can i transact an entity that uses an attribute defined in a different partition from that entity?
attributes are always and only defined in the
db partition; user entities should never be in the
essentially, all your data should be in
:db.part/user unless you need to split it up for index locality reasons.
@danielstockton: partitions are strictly an indexing performance enhancement. there are no restrictions about attributes from multiple partitions being associated with a given entity
makes sense, so you want an entity to be in the same partition as its attributes (typically) so you get more cache hits around them
but it isn't a hard rule, there might be reasons for not having them in the same partition
the entity is simply an ID, which is the first element of a set of datoms, each of which is an attribute/value combination
oh, sorry - getting a little imprecise in this about "attributes" and "attribute definitions"
the idea with partitions is if you have a set of attributes that are likely to be accessed together, then having them in the same partition can improve performance via index locality
i get that, since its encoded in the entityid and therefore they're adjacent in the eavt index and you'll get more segment cache hits
:db.install puts the schema "entity" (attribute definition) into the db partition.
just trying to think why you might want to install a schema entity in a different partition to db.part/db
I would say that it's explicit because it has to be explicit somewhere that you intend to create a schema definition.
the entity id is in the db.part/db partition and it has a :db/cardinality attribute, those are two clues it would seem
it would be surprising for "enforce this as a schema definition" to be implicit behavior.
@marshall: huh? I've not seen that constraint before. Or at least not understood it.
"The attributes you create for your schema must live in the :db.part/db partition."
am i right that nearly everyone uses db.part/user for their data, even though it says its for experimenting (like the default repl namespace)
(aha! I learned something today as well! I've been playing in
:db.part/user by default. 🙂 )
I think it's at least advisable for the same reasons that you shouldn't put your code in the
:user namespace, or in Java in the default package, or in SQL in the "dbo"/"admin" schema/namespace/partition/whatever-your-SQL-calls-it.
but why create a user namespace at all, it seems like most people have taken to using it as the main partition for their data
mhm, should probably be a bit louder in the docs and getting started type tutorials, i imagine its a pain to start building your application and then realise later all your entities are in the wrong partition (especially with datomic)
Is it possible to get a list of transactions? Something like
(d/q '[:find ?tx :where [_ _ _ ?tx]] db)?
@stuartsierra: Perfect, thanks. It seemed a bit hidden, but it's exactly what I need.