lenra-io / server

GNU Affero General Public License v3.0
6 stars 0 forks source link

feat: Find Options - Update components API #552

Open jonas-martinez opened 7 months ago

jonas-martinez commented 7 months ago

About this PR

Closes #

Technical highlight/advice

How to test my changes

Checklist

I included unit tests that cover my changes

I added/updated the documentation about my changes

jonas-martinez commented 7 months ago

@lenra-io/devs I might need help from someone that understands the query_server/view_uid/route_server/lenra_builder features.

I don't understand how I can add my options (skip & limit) params from my view find query. It seems that the work that was done on this only added support for the listeners part of this, this means that it does not work when using the find method in a view.

Can we plan a team meeting to discuss this subject ?

jonas-martinez commented 7 months ago

@lenra-io/devs Finally I found a solution to make it work but I still have one last question about the QueryServer. I added an empty map %{} for each call to ViewServer.group_name() for the options, it works with that but I don't know what is the real purpose of this.

Does someone know what is the purpose of the Swarm.publish with the :data_changed event ?

Example: QueryServer : 440-441

group = ViewServer.group_name(env_id, coll, query_parsed, %{}, %{})
Swarm.publish(group, {:data_changed, new_data})
taorepoara commented 7 months ago

I think that is made to notify the view servers that the data for a given request changed to rebuild the corresponding views

taorepoara commented 7 months ago

You need to fill the PR description

taorepoara commented 7 months ago

For this kind of feature you must add unit tests to check the find requests with and without options

jonas-martinez commented 7 months ago

@lenra-io/devs I might need some help from one of you.

I don't understand how to properly handle the data_changed event with the new "options" object. In fact, the way the projections are currently handled is really weird to me. Let me explain :

When starting a QueryServer, we run a request to Mongo to get the initial data (not applying projections to the request). We get the full data and THEN we apply manually the projection with a Enum.map and Map.filter which seems weird, why not let mongo do it when running the request ?? This also means that the data is never updated if the projection changes. I do not see where is called the Mongo query outside of the initial_data method. At least this is what I understood.

If we want to keep the projection system as is, I will need some help to better understand the core principles of the queryServer and related code.

If we want to let Mongo do the work, a lot of refactoring will need to be done and the system will be MUCH easier.