[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [buckminster-dev] How to improve mapping rules in the Aggregator
I see one immediate problem. That is the 'idPattern' in combination with
the 'versionRange'. It is a problem because there cannot be a clear rule
that selects the best fit. I would much rather see a explicit 'id' then
a 'pattern'. A MapRequest that replaces a MappedUnit must always appoint
exactly one IU (well, or zero if the mapping cannot be resolved).
I think the URI resolution in our ecore model could be rewritten to
actually resolve version ranges without too much effort.
A rule is somewhat different then a MapRequest in my view. A rule can
apply to zero or many mapped things, or even to a whole aggregation. It
all depends on what the rule describes. Ideally, I think rules should be
expressed as p2QL query expressions so that it's possible to say things
like "exclude all translation fragments" or "exclude IU's that include
this property". Using p2QL to define the scope for the rule would also
give us pattern matching for free.
To summarize, I think it's important to keep MapRequest and Rule
separate and that a MapRequest conceptually resovles to one single IU
(best fit) whereas rules are much more open.
Karel Brezina napsal(a):
lately, we've been discussing two aggregator issues. Some of us (I'd
even say most of us :-) ) think that:
1) MappedUnit should be replaced with a MapRequest (id and version would
be replaced by id pattern and version range)
2) MappedUnit and MapRule have much more in common than just IUReference
and should be merged together as a MapRequest
I'm proposing to replace MappedUnit and MapRule with the following
ALL, FEATURE, BUNDLE, CATEGORY, PRODUCT
This model is more general, but proper UI would make it easy to use. It
wouldn't be more complicated to use the aggregator. In some aspects, it
would be even easier. Anyway, it would be open for more advanced features.
- versions of mapped units don't have to be updated every time MDRs are
- it's easier to add more complex exclusion/inclusion rules
- easier implementation (getting rid of proxy references to IU)
Some basic actions:
- d&d an IU from a MDR to a MappedRepo - a new MapRequest would be
created. iuType, idPattern and min. version of the range would be set
according to the selected IU, max. version would be set to infinity,
exclude would be set to false, applyToConfigurations would be empty
- d&d + Ctrl - it would create the same MapRequest, but exclude would be
set to true
The aggregator would have to provide some special actions (views) to
show how the request (or group of requests) would be resolved on the
Do you see any problems with the model I'm proposing? Do you have any
further improvements? Perhaps, do you thing that the current solution is
There are several issue that would be affected by this change (293774,
293083, 293073, 292324), so I'd like to figure out, if there is a will
to improve the aggregator this way.