Read events by event type

[eric-at-rebounded]

I need the ability to query events by event_type
See here https://railseventstore.org/docs/v2/read/
You are lacking the "of_type" function.
example: EventStore.read_events_by_type_forward([OrderCreated])

This is needed for event sourcing when I want to rebuild my "orders" read model table. You typically query for the "initiating" events ("OrderCreated") of the streams ("Order:abc-123") and rebuild the aggregates to dump into the read model tables.

I'll do this myself if you refuse, but you're probably much quicker.

[eric-at-rebounded]

When you're doing this, "streams" are irrelevant. So you'll need a different struct with only the the event table data.

[eric-at-rebounded]

and I think you'll need to do this to construct the query:
in_list_string = "(#{Enum.reduce(types_list, "", fn item, acc -> "#{acc}#{(String.length(acc) > 0 && ", ") || ""}'#{item}'" end)})"

[daveli]

Reading events like this doesn't really fit in a "general" event store. If you wanna have this feature you can look into creating your own custom stream that has all of those events. Like the purposed feature #169 here using https://github.com/commanded/eventstore/blob/master/guides/Usage.md#linking-events-between-streams

[yordis]

I would be conservative about adding functionality that could be done at the application level.

[ericlyoung]

Reading events like this doesn't really fit in a "general" event store. If you wanna have this feature you can look into creating your own custom stream that has all of those events. Like the purposed feature #169 here using https://github.com/commanded/eventstore/blob/master/guides/Usage.md#linking-events-between-streams

I just plain disagree with that statement. it does have a use and there's no definition of a concrete "general event store". see the of_type method here https://railseventstore.org/docs/v2/read/

I did end up writing my own function that does so at the query level and gives me what I need. it COULD (and should) be a part of this lib though.

[ericlyoung]

I would be conservative about adding functionality that could be done at the application level.

It can be, but why would I opt to feed the entire database through my application, when I can filter at the db level and save a lot of cpu time. I suspect you didn't really read/understand my request, and didn't go click the link to see this is exactly present in that [very extensive] ruby library.

[slashdotdash]

I did end up writing my own function that does so at the query level and gives me what I need. it COULD (and should) be a part of this lib though.

Pull requests are accepted if you'd like to contribute this feature.

[ericlyoung]

I would be conservative about adding functionality that could be done at the application level.

your reply is just plain idiotic. this entire library can be done at the "application level"

[ericlyoung]

I did end up writing my own function that does so at the query level and gives me what I need. it COULD (and should) be a part of this lib though.

Pull requests are accepted if you'd like to contribute this feature.

yes, will do so in the future

[yordis]

your reply is just plain idiotic.

@ericlyoung is there any reason to use "idiotic" here? I do not appreciate your response.

this entire library can be done at the "application level"

That was precisely the point, you can have the code outside of the package itself and test things out in your app, and then bring the learning into the package. But as I said, try to be conservative because you can have your own package with such functionalities added.