Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adaptor for EventStore #121

Open
jkears opened this issue Jan 2, 2020 · 4 comments
Open

Adaptor for EventStore #121

jkears opened this issue Jan 2, 2020 · 4 comments

Comments

@jkears
Copy link

jkears commented Jan 2, 2020

This project is awesome however we are not using NEventStore but are using EventStore https://eventstore.org/ with EF Core for projection storage.

Is it possible to create a LiquidProjection Adaptor for EventStore and EF Core? Can this adaptor support streams?

If so and aside from the NEventStore example, has anyone already created an adaptor for either EventStore and/or EF Core persistence? Is there any guidance on how to go about these tasks?

@dennisdoomen
Copy link
Collaborator

Not that I know off. I'm not using EventStore myself, but I would welcome a contribution.

@Corniel
Copy link

Corniel commented Jan 22, 2020

I'm willing to give it a try. Also looking into this at the moment and using EventStore. Is there a guideline on how to do this? (I would advise to go for Dapper to store projections in SQL though)

@dennisdoomen
Copy link
Collaborator

This would require two new repos, e.g. one called LiquidProjections.EventStore and one LIquidProjections.Dapper. I'm not quite sure if ES is an active store that support subscriptions, but if it is, it should be relatively easy. If not, you can use the LIquidProjects.NEventStore repo as an example of how you can use the PollingEventStoreAdapter to build an active adapter.

@Corniel
Copy link

Corniel commented Jan 23, 2020

@dennisdoomen I'm not sure if the Dapper approach requires a package. I would just argue that you should not use EF (Core) period. For insert, it is overhead, and ADO.NET or something as Dapper is sufficient, and for select it is or overhead (with simple select statements), or not performing (complex statements). But that might be seen as off-topic, in which case I appologize.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants