Fork me on GitHub
#onyx
<
2016-11-23
>
Drew Verlee02:11:00

@colinhicks i just loaded up the onyx blueprint and i’m getting some behavior i’m having trouble understanding. The heights of the graphs on the page keep increasing. Visually this looks like their marching downwards. I assume this is something todo with my setup, any ideas?

colinhicks02:11:36

@drewverlee, that's not intentional 🙂. The graph code tries to guess the dimensions of its containing element before it calculates the graph dimensions. I bet the surrounding div doesn't have a width.

colinhicks02:11:25

If that's the case, a quick fix would be to add something like .graph-container {max-width: 500px;} to the css

Drew Verlee02:11:51

Hmm, ok I'll see what I can do in the morning.

colinhicks02:11:37

If it's not straightforward, mind creating an issue in onyx blueprint?

Drew Verlee03:11:00

@colinhicks i made an issue, loos like it only happsn on firefox. When will i learn to just stick with chrome...

colinhicks13:11:05

Just pushed a change to address the tutorial graph marching in FF, @drewverlee. Thanks for reporting it!

martinklepsch15:11:22

I saw some CQRS stuff based on onyx but looking at learn-onyx I'm not immediately seeing how one would make a thing where inputs/outputs are HTTP requests/responses — is that an unnatural thing to do with onyx? If not are there any places where I can read more about this kind of thing?

gardnervickers15:11:34

In CQRS you'd tend to have your queries hit some kind of materialized view of your data, I don't think you'd want to put them through the same path your commands take.

akiel15:11:00

The cheat sheet says that :onyx.core/results is “A map of read segment to a vector of segments produced by applying the function of this task” but in v0.9.12, I get a map with the keys [:tree :acks :segments :retries] in an after batch lifecycle.

martinklepsch15:11:02

@gardnervickers ok but even for Commands you eventually want to deliver a response with some status code etc, no?

gardnervickers15:11:32

@martinklepsch the command response only needs to say that your system successfully received and durably persisted the command.

lucasbradstreet15:11:17

@akiel: that's outdated. We need to fix the documentation

akiel15:11:37

Ok Thanks. I found my way to the new structure.

lucasbradstreet15:11:42

You can get the segments under segments

akiel15:11:25

I use tree, because I like to have the input-output mapping

martinklepsch15:11:53

@gardnervickers thanks, guess I should read up on some CQRS basics 🙂

yonatanel15:11:18

@martinklepsch I believe input to onyx should be available for retries, so instead of directly feeding onyx from http requests, they should first be published to a log such as Kafka

gardnervickers15:11:38

If it helps, think about a database tx-log. The tx log in a db is what tables/views/triggers are all built from. CQRS/ES is just making that tx log an explicit feature in our systems that can be interacted with.

martinklepsch15:11:25

So generally speaking is request/response kind of stuff is out of scope for onyx?

gardnervickers15:11:20

That way, instead of having MySQL’s tx-log only able to build MySQL tables or fire MySQL triggers, you can choose how your log is interpreted and what views/tables of it are persisted.

gardnervickers15:11:26

Yes, Onyx does not support request/response out of the box.

akiel15:11:28

@martinklepsch In CQRS the events are aquivalent to responses in REST.

gardnervickers15:11:17

Events are the action phase in CQRS/ES, bill-customer, add-friend, create-user.

akiel15:11:36

An the events say that a command was sucessful.

akiel15:11:55

So a client has to listen to the event stream.

gardnervickers15:11:20

Successful in that it was persisted only, it does not carry any application level notion of "successfulness"

akiel15:11:31

A command is in imperative like add-friend and the event say friend-added is the successful (in app terms) outcome of the command.

ikitommi15:11:34

Isn't bill-customer a command? customer-billed would be event.

ikitommi15:11:11

@akiel great timing :)

akiel15:11:31

two people can’t be wrong 🙂

gardnervickers15:11:51

However you want to relay successful processing of a command is an application level concern. The important thing is to persist the original command. System state and as a result command completion can be derived from the current position in your log.

martinklepsch15:11:39

Ok, thanks folks!

ikitommi15:11:56

hopefully cqrs/es doesn't turn into rest-kind "you are doing it wrong" paradigm. We have used just simple cqrs for years, without es. Great for building complex uis (both front & back).

akiel15:11:56

@ikitommi Do you have written something about your usage of CQRS?

ikitommi16:11:09

Sorry, no. But talked about it in the first clojutre (2012) & about Kekkonen in ClojureD this year. Could write something.

akiel16:11:16

Ah Kekkonen ok I remember. Thanks.

lellis17:11:04

Hi guys, any way to pass argument to an flow-condition function? like (defn match? [seg my-function-to-match])

akiel19:11:15

I miss the kill job button in the dashboard 0.9.12.0. Am I blind?