https://bugs.documentfoundation.org/show_bug.cgi?id=100367
--- Comment #3 from [email protected] ---
Yes, that's a pretty good explanation.
I don't know whether a "WHERE EXISTS" or some kind of JOIN must be used, I
guess that depends on performance, but that's exactly the idea: the results on
the main form must be filtered ALSO by conditions defined in the subforms.
The case 1:1 is a case where this makes a lot of sense, but it also makes sense
in 1:N or M:N cases.
In 1:N cases, for example: assume we have "Companies" and "Branches", each
company has 1..N branches, and each branch belongs to 1 company. Branches
include a postal address, and thus, a city. It seems reasonable to be able to
filter the main form (Companies) trying to select those that have branches in
some specific cities, regions, etc. And that data lives in the subform
(branches table). The same is true if we add a third subform corresponding to a
"year_sales" table related to "branches". If a user wants to select companies
with a branch with year_sales higher than a given figure and with branches in
some specific cities, this proposed enhancement would allow them to do it from
the main form/form-based-filter.
This particular example, also, exposes some undefined behaviour that should be
clarified. For the company -> branch -> year_sales case, defining a "City =
Barcelona" AND "year_sales > X" filter could result in two possibilities
(additional to the current behaviour):
a) Select companies that have a branch located in Barcelona and have some
branch with year_sales > X
or
b) Salect companies that have a branch located in Barcelona with that specific
brach having year_sales > X
I guess that the proposed GUI change should allow to specify to which
parent-form the subform condition should apply (when we want it to apply to
parent forms)
For the M:N case, just think about a item <-> tags relationship. Being able to
select some items by some attributes AND having some tags assigned also looks
reasonable.
As I stated in my original report, AFAIK, the only way to perform those filters
right now is to define an ad-hoc/synthetic query and an associated form to see
the data upside-down (duplicating efforts/work) or to use some kind of
single-row search-table that also uses synthetic data (the filter
configuration) to filter the orginal form. The problems with those appropaches
are that (a) they have to be rethought/redone to add/remove search criteria and
(b) are not business-user friendly.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
