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

Generalize Cosmo Store #10

Closed
kunjee17 opened this issue Feb 6, 2019 · 17 comments
Closed

Generalize Cosmo Store #10

kunjee17 opened this issue Feb 6, 2019 · 17 comments

Comments

@kunjee17
Copy link
Contributor

kunjee17 commented Feb 6, 2019

@Dzoukr Loved your work. Is it possible abstract away the implementation to make is more generalize.

I was trying Marten Event Store but it was tied with C# thingy for project part of it. But Marten as store is wonderful.

And then there is lite db for simple testing or simple application. I am noob at ES so can't say how complicated it would be. But it would be good to have it.

@Dzoukr
Copy link
Owner

Dzoukr commented Feb 6, 2019

Hi Kunjal,
thanks a lot! If I got it right, you would like to have something like CosmoStore.Facade or CosmoStore.Interface and having Azure Table Storage & Cosmos DB as let say implementation of this? Then there can be other parts like CosmoStore.Marten, CosmoStore.MongoDB, and so on... Is it correct?

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 6, 2019

@Dzoukr yup... Very much correct.

@Dzoukr
Copy link
Owner

Dzoukr commented Feb 6, 2019

Funny... I'll need MongoDB version most likely pretty soon and was thinking about the same. It would mean to break and existing setup a little bit (TableStorage and CosmosDB would go into separated nuggets), but on the other hand since I follow the semver, it should be doable for next major version.

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 6, 2019

When you are planning to have next version?

Side note: Don't use mongo db, if it is not forced by client.

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 6, 2019

Btw Maxime is having set up to push multiple nugets https://github.com/Fulma/Fulma/blob/master/build.fsx

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 6, 2019

@Dzoukr
Copy link
Owner

Dzoukr commented Feb 6, 2019

Not before start of March, sorry.

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 6, 2019

Oh no need for sorry. I was just asking out of curiosity. And if you require any help the please do let me know... Happy to help in whatever way possible.

@Odonno
Copy link

Odonno commented Feb 6, 2019

Maybe more CosmoStore.Core instead of Facade or Interface, don't you think? So, you will reuse core logic with each database API (inside each package).

@Dzoukr
Copy link
Owner

Dzoukr commented Feb 7, 2019

FYI, I already did some work in master, but want to have version 2 with new functionality (tracking by correlationId + adding causationId), so it is gonna be probably during March.

Expected architecture:

  • CosmoStore (basic definition how ES should look like) - separated Nuget
  • CosmoStore.CosmosDb (Cosmos implementation) - separated Nuget
  • CosmoStore.TableStorage (Table Storage implementation) - separated Nuget

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 8, 2019

@Dzoukr I have no idea about those two ids. But again thanks for support and I don't mind waiting.

One suggestion if you don't mind. Create a v2 issues and announce in community for contribution. It might help you to go faster.

Fulma is too damn big library. I created GreenPrint similar way. Maxime is crazy good person when it comes to throw code out of windows but still having good guideline for contribution and separated issues which people can pick will always going to help.

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 8, 2019

BTW separated nuget is really good idea. You can have something like CosmoStore.Core as well. I am not big fan any naming convention though. But it will surely allow community to come up with different ES store implementation based on Core definitions.

Don't want to increase your burden but shouldn't the name be changed? Cosmo is based on ConsmoDB and now it would be generalize.

@Odonno
Copy link

Odonno commented Feb 8, 2019

I agree. The name CosmoStore is too close to the implemented CosmosDb database but in the same time I really like the name CosmoStore.

@Dzoukr
Copy link
Owner

Dzoukr commented Feb 8, 2019

I'll most likely keep the CosmoStore name. It may sounds similar to Cosmos DB, but I'd to keep some continuity + I like the name. :)

@kunjee17
Copy link
Contributor Author

kunjee17 commented Feb 8, 2019

I also like the name. But again it is very near to ConsoDB. Let's do one thing. Make it more famous than ConsoDB. :P . That way they might need to change a name.

Dzoukr added a commit that referenced this issue Feb 12, 2019
Dzoukr added a commit that referenced this issue Feb 12, 2019
@Dzoukr
Copy link
Owner

Dzoukr commented Feb 12, 2019

Just release beta versions of v2.

Each CosmoStore implementation will be in separate package where CosmoStore is only API definition.

Please check it (I will do the same) and will release full version probably this week. :)

@Dzoukr
Copy link
Owner

Dzoukr commented Feb 12, 2019

Proper v2 release now public. Thanks for hint! 🙏

@Dzoukr Dzoukr closed this as completed Feb 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants