Home » Archived » B3 » Aggregator debate - take 2
|
| Re: Aggregator debate - take 2 [message #517371 is a reply to message #517341] |
Sat, 27 February 2010 10:15   |
 Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
This was almost possible in my experimental implementation. I must say "almost" because the whole repository R1 was available
to the final process for resolving dependencies. I guaranteed that the user got what explicitly selected, but
he could not control where the dependencies come from.
Example:
Repo A contains:
a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
x.y.z/1.1.0
Repo B contains:
d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
x.y.z/1.4.0
a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
User A (in contribution A) requires
a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)
User B (in contribution B) requires
d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo contains only 1.0.0, I think he expect this to be chosen)
Algorithm 1)
The result of the aggregation AS IT STANDS TODAY is:
a.b.c/1.1.0.beta from B - since it is the best match for A's request for a.b.c/[1.0.0,MAX]
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX]
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request
I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
d.e.f/1.0.0 from A - since it the best match of B's request for d.e.f/[1.0.0,MAX] from the repository where user B defined his request
x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and d.e.f's dependency request, the scope for searching the dependencies is not limited
I think that with current model it should work like alg. 2).
If we say that alg. 1) is correct (I don't say it is incorrect!), then we should change the model and the UI.
In my view, both are correct! But then, we should change the model, the UI and add options to specify explicitly the scope of resolution. One of the algorithms becomes the default.
I would prefer to have a beer, a big table (not talking about software but real wooden table), a pen and a sheet of paper... and find the best solution :-)
Filip
Henrik Lindberg wrote:
> Hi,
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
>
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
>
> This way, my end result includes only the items I really wanted to get
> from R1.
>
> Will this handle the case Achim brought up?
>
> If so, how can the above be supported using only one aggregation?
> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
>
> Regards
> - henrik
|
|
|
| Re: Aggregator debate - take 2 - CORRECTION [message #517372 is a reply to message #517371] |
Sat, 27 February 2010 10:18 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Sorry, I made a little mistake that may confuse you. Here is a correction:
....
Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
^
here is the mistake, should be a.b.c/1.0.0 from A (version 1.1.0 does not exist in A)
....
Filip
Filip Hrbek wrote:
> This was almost possible in my experimental implementation. I must say
> "almost" because the whole repository R1 was available
> to the final process for resolving dependencies. I guaranteed that the
> user got what explicitly selected, but
> he could not control where the dependencies come from.
>
> Example:
>
> Repo A contains:
>
> a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.1.0
>
> Repo B contains:
>
> d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.4.0
> a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
>
>
> User A (in contribution A) requires
> a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
> User B (in contribution B) requires
> d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
>
> Algorithm 1)
> The result of the aggregation AS IT STANDS TODAY is:
>
> a.b.c/1.1.0.beta from B - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX]
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX]
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request
>
> I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
>
>
> Algorithm 2)
> The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
>
> a.b.c/1.1.0 from A - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX] from the repository where user A defined his request
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX] from the repository where user B defined his request
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request, the scope for searching the dependencies is
> not limited
>
>
> I think that with current model it should work like alg. 2).
> If we say that alg. 1) is correct (I don't say it is incorrect!), then
> we should change the model and the UI.
>
>
> In my view, both are correct! But then, we should change the model, the
> UI and add options to specify explicitly the scope of resolution. One of
> the algorithms becomes the default.
>
>
> I would prefer to have a beer, a big table (not talking about software
> but real wooden table), a pen and a sheet of paper... and find the best
> solution :-)
>
> Filip
>
>
>
> Henrik Lindberg wrote:
>> Hi,
>> been thinking about this and wonder if the use case under debate is
>> achieved by the following:
>>
>> - Repository R1 is mirrored to R2 and configured to only mirror
>> component A (and what it requires).
>> - In a second aggregation I use repository R2 and aggregate this with
>> a bunch of other repositories.
>>
>> This way, my end result includes only the items I really wanted to get
>> from R1.
>>
>> Will this handle the case Achim brought up?
>>
>> If so, how can the above be supported using only one aggregation?
>> The extra repository creation step seems unnecessary to enable "cherry
>> picking" - a use case that I think is not too uncommon.
>>
>> Regards
>> - henrik
|
|
|
| Re: Aggregator debate - take 2 [message #517381 is a reply to message #517341] |
Sat, 27 February 2010 10:36 |
|
On 02/27/2010 01:58 AM, Henrik Lindberg wrote:
> Hi,
> been thinking about this and wonder if the use case under debate is
> achieved by the following:
>
> - Repository R1 is mirrored to R2 and configured to only mirror
> component A (and what it requires).
> - In a second aggregation I use repository R2 and aggregate this with a
> bunch of other repositories.
>
> This way, my end result includes only the items I really wanted to get
> from R1.
>
> Will this handle the case Achim brought up?
>
That case is already handled since the planner prevents results that are inconsistent.
> If so, how can the above be supported using only one aggregation?
You use a version range that is restrictive enough to give you the A that you want.
> The extra repository creation step seems unnecessary to enable "cherry
> picking" - a use case that I think is not too uncommon.
>
Using id + versionRange should give you all the cherry picking capabilities you need. That's of course unless you think
that the same IU found in different repositories really are different IU's (a view that in itself opens up a whole new
can of worms).
- thomas
|
|
| |
| Re: Aggregator debate - take 2 - CORRECTION [message #600230 is a reply to message #517371] |
Sat, 27 February 2010 10:18 |
Filip Hrbek
Messages: 233
Registered: July 2009 |
Senior Member |
|
|
Sorry, I made a little mistake that may confuse you. Here is a correction:
....
Algorithm 2)
The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
a.b.c/1.1.0 from A - since it is the best match for A's request for a.b.c/[1.0.0,MAX] from the repository where user A defined his request
^
here is the mistake, should be a.b.c/1.0.0 from A (version 1.1.0 does not exist in A)
....
Filip
Filip Hrbek wrote:
> This was almost possible in my experimental implementation. I must say
> "almost" because the whole repository R1 was available
> to the final process for resolving dependencies. I guaranteed that the
> user got what explicitly selected, but
> he could not control where the dependencies come from.
>
> Example:
>
> Repo A contains:
>
> a.b.c/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.1.0
>
> Repo B contains:
>
> d.e.f/1.0.0 which depends on x.y.z/[1.0.0,1.5.0]
> x.y.z/1.4.0
> a.b.c/1.1.0.beta which depends on x.y.z/[1.0.0,1.5.0]
>
>
> User A (in contribution A) requires
> a.b.c/[1.0.0,MAX] defined under Repo A (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
> User B (in contribution B) requires
> d.e.f/[1.0.0,MAX] defined under Repo B (he can see that the repo
> contains only 1.0.0, I think he expect this to be chosen)
>
>
> Algorithm 1)
> The result of the aggregation AS IT STANDS TODAY is:
>
> a.b.c/1.1.0.beta from B - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX]
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX]
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request
>
> I think that user A may be surprised where a.b.c/1.1.0.beta comes from.
>
>
> Algorithm 2)
> The result of the aggregation AS IT WORKED IN MY EXPERIMENT is:
>
> a.b.c/1.1.0 from A - since it is the best match for A's request for
> a.b.c/[1.0.0,MAX] from the repository where user A defined his request
> d.e.f/1.0.0 from A - since it the best match of B's request for
> d.e.f/[1.0.0,MAX] from the repository where user B defined his request
> x.y.z/1.4.0 from B - since it is the best match for both a.b.c's and
> d.e.f's dependency request, the scope for searching the dependencies is
> not limited
>
>
> I think that with current model it should work like alg. 2).
> If we say that alg. 1) is correct (I don't say it is incorrect!), then
> we should change the model and the UI.
>
>
> In my view, both are correct! But then, we should change the model, the
> UI and add options to specify explicitly the scope of resolution. One of
> the algorithms becomes the default.
>
>
> I would prefer to have a beer, a big table (not talking about software
> but real wooden table), a pen and a sheet of paper... and find the best
> solution :-)
>
> Filip
>
>
>
> Henrik Lindberg wrote:
>> Hi,
>> been thinking about this and wonder if the use case under debate is
>> achieved by the following:
>>
>> - Repository R1 is mirrored to R2 and configured to only mirror
>> component A (and what it requires).
>> - In a second aggregation I use repository R2 and aggregate this with
>> a bunch of other repositories.
>>
>> This way, my end result includes only the items I really wanted to get
>> from R1.
>>
>> Will this handle the case Achim brought up?
>>
>> If so, how can the above be supported using only one aggregation?
>> The extra repository creation step seems unnecessary to enable "cherry
>> picking" - a use case that I think is not too uncommon.
>>
>> Regards
>> - henrik
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 14:11:41 GMT 2024
Powered by FUDForum. Page generated in 0.02229 seconds |
] 
Search
Help
Register
Login
Home
