This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-13
Channels
- # admin-announcements (296)
- # beginners (19)
- # boot (40)
- # cider (77)
- # clojure (139)
- # clojure-australia (2)
- # clojure-bangladesh (6)
- # clojure-dev (19)
- # clojure-japan (25)
- # clojure-russia (23)
- # clojure-sg (1)
- # clojure-uk (4)
- # clojurescript (131)
- # datomic (41)
- # editors (42)
- # ldnclj (35)
- # off-topic (11)
- # reagent (10)
Any advice on how to structure data for an elementary school report card? There are numeric metrics Several lists and text fields… but I’m hoping to keep them flexible; So the data might be:
[{:db/id 3
:components [[:metrics "Metrics" ["Productivity"
"Leadership"
"Happiness"]]
[:ol "Achievements" ["Won the spelling bee."]]
[:ol "Weaknesses"]
[:ol "Coach goals"]
[:ol "Player goals"]
[:textarea "Coach comments"]
[:textarea "Player comments"]]}])
Bearing in mind that the categories might change.
I’m thinking I should be using :metric/happiness :comments/coach instead of nested data… but it feels like then I have some path info tied up in my keywordsAlternatively maybe I should be making a new entity for ‘metrics’ and ‘achievements’ etc
If I'm reading your intentions here correctly, I think there's a mismatch between what you're attempting in the code snippet, and what datomic does -
okay, when you say "the categories might change", what part of the snippet are you referring to?
new/different metrics for example “Math"
and new categories
like a list of friends or something I haven’t thought of
yes, though I don’t have any special meaning to ‘category’
a student entity would have these (optional) attributes: :metrics
, :achievements
, :weaknesses
, :goals
, and :comments
:metrics
, :achievements
, and :weaknesses
look like they can just be db.type/string
with :db.cardinality/many
is there a way to preserve order in a many relationship? or would I need to make them entities that relate to each other to do that?
ordering isn't really straightforward - the easiest way to do it, imo, is to give the things you want to order an :order
attribute and sort in your client code
so if you need to order those first three, you'd need to make them entities, rather than just strings
ah nice
:goals
and :comments
would be entities in their own right, because you need to note authors
they'd just have an attribute for the goal or comment, and then another attribute to note the author - either an enum-like thing if you just want it to be :coach
or :player
, or you could represent people as their own entities and refer to them from there
gotcha
thanks that makes a lot of sense
is there a shorthand way to insert my root with it’s various sub-entities, or should I write a transformation from my datastructure that produces all the entities and throw them at transact?
Can't link you directly to the content, but search for "nested" here: http://docs.datomic.com/transactions.html
also, note that even though the syntax for nesting uses vectors, the entities don't end up being ordered in datomic
ooo great!
thank you very much
@bhagany: cool, I didn’t know about that. every once in a while you need to re-read the datomic docs for added features
hi nice people one question: if I do a transaction using upsert, but nothing is changing (let's say I'm transacting data with the same value that is already on the DB), this will create a new transaction anyway or it's going to skip since nothing was going to change?
@wilkerlucio: that will create a new transaction
thanks @arohner, so I think I'm better do a query to check if the data is the same to avoid unintended history I think
@wilkerlucio: depends on what you’re trying to do. Re-asserting a fact can be a valid strategy as well. “on today’s date, I observed X to still be true"
@arohner: my case is just a simple facebook login, I'm actually login at the client-side, I just send the access token and then I create/read the user ID, is on that point that I was going to always transact (in case it didn't generate a new one), but since it does I'll just check if the user is there and avoid when it is. makes sense?