Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2019-05-09

Channels

#datomic
<
2019-05-09
>
hadils13:05:13

Thanks @val_waeselynck! This is an excellent idea. I already named my keys and I don't have the opportunity to go back and rename them. Also, there is no single name for each key that satisfies GraphQL and my external APIs. I will keep this in mind for my next project.

Daniel Hines14:05:38

Isn’t namespace keywords to some sort of concatenated string a bijective transformation, such that you can really simply convert from one to the otehr?

Daniel Hines14:05:29

Kind of like camel case to hyphenated, etc.

favila14:05:17

It's not bijective. :a_b.c -> :a_b_c -> :a.b.c

favila14:05:24

you would have to add some unambiguous escaping mechanism to know that a character was in the original rather than the result of a transformation. Or reject certain input, also an option

danieroux14:05:02

I settled on :a.b/c -> a_b__c - it makes SQL happy, and it doesn't offend my sensibilities too much.

val_waeselynck19:05:24

Even when converting the names is easy, I don't think it's beneficial. When you do that, you lose the ability to instantly trace the lifecycle of a piece of data across your whole system, with a basic text search.

val_waeselynck19:05:27

It's OK for key names to not be Clojure-idiomatic. (Just like it's OK for your language to use parens instead of curly braces... sounds familiar? :) ).

😆 4
val_waeselynck19:05:27

Actually, a key name that doesn't respect Clojure's namespacing convention signals that it's meant to travel across the system, in contrast e.g with component or algorithm configuration. This contrast adds clarity.

Daniel Hines19:05:12

That’s a good point - data “from the system” would stick out for having the odd_naming__conventions.

calebp20:05:10

Hey all, the cloud docs have instructions for “First Upgrade Ever” but these instructions don’t apply if I used the instructions here https://docs.datomic.com/cloud/operation/new-system.html and created the stacks individually, right? It looks like I can just go forward with the regular stack upgrade instructions.

marshall21:05:10

if you’re already running a split stack you can go right to the regular upgrade

wei23:05:46

is there a way I can rewrite this pull query so I can get nil when the query doesn't find any results? 

=> (d/pull (db/db) '[*] [:account/email "doesn't-exist"])
#:db{:id nil}

marshall23:05:38

You want the default option for your pull Express

wei23:05:02

thanks @marshall. to clarify, I want this output: 

=> (d/pull (db/db) '[*] [:account/email "doesn't-exist"])
nil
It's currently returning #:db{:id nil}

wei23:05:19

also, this works for the cloud client api right?