Postgres / Marten Support


#1

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.


#2

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.


#3

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?


#4

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.


#5

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:

image


#6

Hi,

  • MongoRoleStore
  • MongoUserStore

are part of ASP.NET Identity. There could be an implementation for that.

  • MongoPersistedGrantStore

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.


#7

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.


#8

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?


#9

There are already interfaces :wink: