Implement search for list user service

[mirceaalexandru]

Should allow this:

/api/user?limit=10&skip=20&q=.... ?

[mirceaalexandru]

@mcdonnelldean did you decide which DB engine we will use?

[mihaidma]

We'll probably have like thousands of users, labels on them, maybe some auditing. The data volume is not so big but probably there will be data read traffic, not so much write.

[mihaidma]

postgres? we could test the work I currently do on it.

[ckiss]

I would say postgres as well. we can swap it along the way anyway if needs be.

[mirceaalexandru]

@ckiss

Well there are two things that are not implemented at store level, and because of that should be implemented using the native driver. Those are the reasons I did not implement this issue until we do know what DB we will use:

• count
• search based on regex

In my opinion those should be also implemented at store level but for now are available only by using the native driver.

Because of those, switching the store will require code changes in Concorda.

[AdrianRossouw]

these is this : https://github.com/AdrianRossouw/seneca-massive-store

It's a postgres entity store that uses massive.js in the backend, which is a lot more flexible/powerful
than the existing entity store and would allow you to leverage regex / counts.

Unfortunately I needed to stop working on it before there was an actual project it could be used on,
so there may be rough edges.

here's more on what it can do : https://gist.github.com/AdrianRossouw/13a66c38d67f280982fc

[mirceaalexandru]

Thank you @AdrianRossouw

We need to decide which plugin to use, massive-store or what id doing now @mihaidma but as I said the actual implementation of postgres store is missing those important (for us) features.

[mcdonnelldean]

If @AdrianRossouw can't give time to the massive plugin I would rather start with @mihaidma's one. Whichever is the safest bet now is the better option. We don't have complex structures so a swap out would be a day or two of work.

[AdrianRossouw]

understood @mcdonnelldean, I was just sharing the info.

My concern with the massive store is that there hasn't been anything built with it yet, but I do know
that you should be able to easily build the queries for that.

My concern with the store query stuff that mihai is working on is that adding those missing
features could affect all the stores, and could potentially have a lot larger impact code-wise.

Perhaps a good compromise would be to use the postgres-store, and handle anything
more complex than it can easily cope with at the moment using ent.native$ ?