This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-13
Channels
- # 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?
@danielstockton: That is my understanding.
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
ah yes, so it is
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
can't the partition be inferred from the tempid anyway?
@danielstockton: Not an expert, but there is also :db.alter/_attribute
so it doesn't have to be :db.install/_attribute
i guess that could also be inferred, if the ident already exists
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.
(remember that :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
it just depends whether you use the eavt or vaet index
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
hmm, why does an attribute need to be installed in a specific partition then
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.)
yeah, thats why i wonder if it can't be inferred
:db/cardinality is a reserved attribute, it could tell the transactor that 'this is a schema entity'
by very extremely inappropriately coarse analogy to SQL: DDL does different things than DML.
or there could have been a different function transact-schema
it makes me think there is some leverage to be had from it
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 db
partition.
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"
yeah, think i was getting them muddled too
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
right. :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
why that's explicit in the transaction, rather than just inferred
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
i don't know, it seems strangely verbose
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.
what else would you be transacting into #db.id[:db.part/db]?
ah and functions maybe?
"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 haven't ever seen any justification for that advice though
it seems to me like you'd usually have a totally separate db for experiments
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
yeah, fair point
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)
with datomic, you kind of have to get things right from the beginning
Is it possible to get a list of transactions? Something like (d/q '[:find ?tx :where [_ _ _ ?tx]] db)
?
@sdegutis: yes, with the Log API
@stuartsierra: Perfect, thanks. It seemed a bit hidden, but it's exactly what I need.