Hi, before I embark down the proverbial rabbit hole, I wanted to get some insight on how large of a task it would be to port the data layer over from Mongo to Postgres (using marten). I love the product and found it after I was rolling my own from scratch. I plan on building some fairly large sites (lots of data) using squidex, however, I don’t know or like mongo. Postgres + CitusDB + Marten can definitely handle massive amounts of load etc. Let me know if I should bother creating a new data access layer. Meanwhile, I shall peruse the code and see if I can wrap my head around the inner workings.
Most of the stuff is really easy. But there are 2 collections that are hard to port. It is the Contents and the assets.
it would be great if as much as possible would be SQL-DB agnostic with EF-Core or some other layer.
What makes those two collections tough to port? Marten takes advantage of Postgres’ json and jsonb column/data structures and can store json natively (and they are queryable, etc…). Maybe there is something that I’m missing?
For example you have to port the query system to Marten. It is not particular hard but just much more work than the other collections.
So what would be the main class I should look at to create a Postgres DAL? MongoRepositoryBase? I would assume all of these classes would have to be replaced:
are part of ASP.NET Identity. There could be an implementation for that.
belongs to Identity Server.
But the rest must be implemented. There could be a way to replace MongoMigrationStatus with the MongoSnapshotStore and delete the whole interface.
Great, thanks for the info - I plan to have squidex running in a Mongo-less environment. So this is the info I need, thanks! Will provide updates here.
So wait, another thought - shouldn’t the data access layer(s) / repositories be injectable? I’m hoping that maybe you guys would consider incorporating the postgres bits into the main project. If that’s the case, I can try and create interfaces, etc that can be injected where consumed and can be configured in the startup or somewhere. Any ideas?
There are already interfaces