[DECLINED] Make content DB more configurable

[seamys]

Hi, @Sebastian

Currently, Squdiex has 1 content store implements(MongoDB). but in the future maybe we have more.

Dose squiex can make content DB more configurable by app or even schema.
if that it will bring much more benefit.

if content DB is heavy, we may need separate content DB by the app. so we don’t need to worried different app impact each other.

high-performance, without history and stableness, Redis DB or other memory DB,
For example:
Session: the session alive time only for 20 mins if the user no longer accesses it. we can create a high-performance content of schema to store the session. the management portal can manage them.

communicate bridge:

[DECLINED] No version fields support

Hi @Sebastian I’m trying to using squidex do some cool things. [image] Using squidex be communicate bridge to separate the frontend(Web) and backend(console or service). so fronend only need do: upload file create content looping content status backend: read file from content hub. keep update statue to content. so my question, can we make some field no version. like sitecore cms, because every time the backend change the content squiex will create a history. [image]

Thank you bring such a fixable system to this world,

[seamys]

I know there has lots of work if we implement it. i just would like to see it in the future.

[Sebastian]

In general it depends on the store how to implement that I would say:

I have decided for this implementation for several reasons:

1. The cloud version would have thousands of databases when there would be one database per app and ten-thousands of collections if it would be one collection per schema.
2. Migrations are much harder and less performent when there are so many databases and collections.
3. I do not see a lot of performance improvements, because whenever possible I use indices. I would say it could be even faster to have less collections and databases performance the memory usage of the database is probably lower.

About Redis: It would have no improvement at all. Stuff like content and assets are hard to cache anyway and the apps and schemas and rules are queried from the Orleans actors which works like a cache. When you use an app the app stays in memory until it is not used anymore for more than 20 minutes. Whenever you need information from an app in this timeframe it is just like a lookup in a in-memory-cache. If the app lives on another server there is also a network roundtrip and serialization, which is usually very fast (1-2ms).

[seamys]

I’m great to have that information from you.
sorry, I didn’t make my question clear.

I mean, when users create app or schema, they can decide which kind of database they want to use(MongoDB, Amazon DynamoDB). so different app or event schema can have a different type of DB.

so just need to make some type of content in the cache. apps and schema can continue using in MongoDB

anyway, I know your points.

Thanks

[Sebastian]

This is even more complicated.