Fork me on GitHub
Slack Archive

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

2020-02-23

Channels

#datomic
<
2020-02-23
>
currentoor16:02:42

Ah thanks, exactly the advice I was hoping for

em20:02:44

Trying to puzzle out not-join and when it is necessary. The docs example is: 

[:find (count ?artist)
 :where [?artist :artist/name]
        (not-join [?artist]
                  [?release :release/artists ?artist]
                  [?release :release/year 1970])]
The docs mention this means that ?artist is the only variable unified and the other inside the not-join, namely ?release, is not. Why would a simple (not) clause here not work, if there doesn’t seem to be a ?release to be unified outside the clause anyway? Or is this just some kind of performance thing?

joshkh20:02:06

if i'm reading the docs correctly, one needs to split their solo stack in order to upgrade datomic. are there any disadvantages to doing this (e.g. pricing)? and if not, then why does the solo topology start with a combined stack?

em20:02:19

@U0GC1C09L The master combined stack is necessary for the AWS Marketplace integration, but makes operational tasks harder for Datomic, as architecturally the persistent storage stack and the compute nodes are separate. For example, you could take down the compute nodes completely and your underlying storage would be unaffected, allowing you to upgrade either separately or do whatever you want. For solo the system is so small (and has no HA guarantees) so it’s fine to lump everything together, but for production you’ll need to split the stacks (or more correctly “untangle” them because they weren’t meant to be together anyway). There’s no pricing disadvantage to split stacks, the same resources are just described in two cloudformation templates.

joshkh20:02:25

> The master combined stack is necessary for the AWS Marketplace integration cool, that answers my question. i'm coming from the production->solo perspective for hobby purposes. thanks @UNRDXKBNY