start / limit parameters (passed from the client or set on the server) only control pagination behavior, not the total limit on data returned from the DB (see #674). We should introduce another kind of limit - a server-side "hard limit" that translates to SQL LIMIT clause. It will not have a matching start and will not be affected by pagination controls or server-side row filtering. The total returned in the response will never exceed the hard limit (as all the paginated queries will bump into it and will not be able to tell that there are more rows than the limit).
Let's call itmaxLimit, as it is very similar to how maxPathDepth operates. However, it will be applied per-entity, not per-request (cause limits would normally depend on the row count in a given table). Hence, it will be available through AgEntity / AgEntityOverlay API.
Note that this will make #674 less relevant, and will address the intent of #592.
start/limitparameters (passed from the client or set on the server) only control pagination behavior, not the total limit on data returned from the DB (see #674). We should introduce another kind of limit - a server-side "hard limit" that translates to SQL LIMIT clause. It will not have a matchingstartand will not be affected by pagination controls or server-side row filtering. Thetotalreturned in the response will never exceed the hard limit (as all the paginated queries will bump into it and will not be able to tell that there are more rows than the limit).Let's call it
maxLimit, as it is very similar to howmaxPathDepthoperates. However, it will be applied per-entity, not per-request (cause limits would normally depend on the row count in a given table). Hence, it will be available through AgEntity / AgEntityOverlay API.Note that this will make #674 less relevant, and will address the intent of #592.