from ServiceProvider
Although it’s best to be careful and avoid such need ;)
Using external dependencies introduced deterministic behaviours and performance degradation in our case.
Of course, sometimes it’s right and justified, but it better double-check if it’s really needed.
I'm leaning toward an all new page that's dedicated to handling CQRS commands, but I'd be very happy to have any suggestions for what that page would even be called
@jeremydmiller, I’d also vote for a dedicated page. I’m not sure if it has to be named CQRS. To not make some people defensive, maybe “Handling Business Logic” would be better and then inside mention CQRS.
Just re-looking, alternative is to put it in https://martendb.io/scenarios/aggregates-events-repositories.html where we are talking about different scenarios. So this could be in a scenario based explanation.
in addition, put it under
appending as well for each method. Also a a link to a section in the above mentioned page with a short explanation.
Probably, the above is better...
@jeremydmiller PR's JasperFx/marten#2322 (merged recently) and JasperFx/marten#2310 look to be related. Possibly, we can close #2310 as well?
Hi all, I've watched the great videos last week by Jeremy and Oskar, and had a quick play with the event sourcing stuff. I'm missing something fundamental in how projections work though, and wonder if anyone would be able to spare 10 mins to tell me what I'm doing wrong. I think everything needed to repro is here: https://gist.github.com/slovely/ee50e8ffb318d604473ed66c585d17b5
Basically, I've created a couple of events and have a SelfAggregating projection, but only the most recent event seems to be reflected in the projection. See the comment on the gist for the full repro steps. My understanding could be wrong, but I thought that the projection would contain the latest state of all the events.
Thanks very much,
Simon
Basically, I've created a couple of events and have a SelfAggregating projection, but only the most recent event seems to be reflected in the projection. See the comment on the gist for the full repro steps. My understanding could be wrong, but I thought that the projection would contain the latest state of all the events.
Thanks very much,
Simon
@mysticmind Yeah, I didn’t notice that the PR came in with the fix before I dealt with that. The fix I did is more generic and should go forward. I thought we could take in his test code as another regression at least. I just didn’t get around to doing the merging yet
1 reply
@slovely You’re wiping the data in the database between tests is the first thing: https://gist.github.com/slovely/ee50e8ffb318d604473ed66c585d17b5#file-marteneventstoretests-cs-L33
But I could definitely be doing something wrong!
@jeremydmiller @oskardudycz OK doing that has lead me to discovering the issue! (should have explained it to a rubber duck first!). The problem is resolved if I change the properties on the projection to not have a private setter. I shouldn't have assumed that Marten would use reflection!
You can set the private members handling options also to allow private ones.
The important thing is I have a field named Id with getter and setter
See also https://martendb.io/documents/identity.html about identities
Appreciate the help guys!
Hello :) I have a question regarding projections. Is there any guarantee on the order of projections processing (especially when rebuilding)?
Since built-in projections can take
Alternatives I can think of, are keeping "helper" documents or doing live aggregations for lookups
Since built-in projections can take
IQuerySession for doing additional lookups, I wonder if it is feasible to query against documents generated by other projections? But for that, we'd need to have some guarantees on the order of processing.Alternatives I can think of, are keeping "helper" documents or doing live aggregations for lookups
Typically, it's best to avoid having dependencies between projections for that reasons.
@migajek What Oskar said, but I'm somewhat in favor of possibly changing that in the long term. That being said though, I do think you could use the build products of an inline projection in an async projection -- but it'd be on you in the rebuild to make sure the inline projections are executed before the async projections if needed.
When I did the last big overhaul of the
projections command I almost changed it to rebuild inline projections first before starting the async, but punted on that
I have a dedicate container task that is triggered on deployment that manages the rebuilding or projections, using our own state table to detect what has changed since last deployment (new models, old ones removed etc). The main reason this was needed was to ensure inline projections are backfilled.
Thanks for all the answers!
quite some time ago when I previously used Marten extensively (probably around 4 years now, wow!) I made a PR that made it to the Marten allowing the projection to manage multiple document types; thus - allowing building "helper" models, so that the projection was not dependent on the others. It looks the code is long gone after the overhauls (BTW must admit the projections stuff makes much better impression nowadays :) ) but the idea seems to have stayed there - there's the
quite some time ago when I previously used Marten extensively (probably around 4 years now, wow!) I made a PR that made it to the Marten allowing the projection to manage multiple document types; thus - allowing building "helper" models, so that the projection was not dependent on the others. It looks the code is long gone after the overhauls (BTW must admit the projections stuff makes much better impression nowadays :) ) but the idea seems to have stayed there - there's the
Published Type concept in the ProjectionBase. Will try to implement something around that :)