Hi David,
The traverse query was written with the intention to replace the slicer
but we never got around to actually do that in the 3.6 time frame. As it
stands today, it's not a clean cut replacement. The slicer (permissive
or non-permissive) will give you specific control over the query that is
applicable for a couple of use-cases that is utilized by the PDE target
platform provisioning system. One is for instance to guess whether a
requirement stems from a PDE-feature 'include' or a PDE-feature
'requires' by looking at the version range (exact or not) in the
requirement. The traverse query is generic and not capable of performing
special considerations like that. It is however proven to be both faster
and more memory conservative than the slicer so I guess the answer to
your question all depends on your requirements. It would be easier to
give a good answer if we knew more about what it is you want to accomplish.
Regards,
Thomas Hallgren
On 2010-12-10 20:35, David Orme wrote:
Pascal and Tomas,
Thanks for both of your assistance. I've found the slicer example
Pascal referred me to and think I understand the query examples. A
couple more questions:
Which approach is preferred? It seems like the query interface might
result in code that is easier to understand at a high level, but maybe
I haven't understood the slicer deeply enough yet. I note that the
query interface is advertised as being marginally faster.
Is there an example anywhere putting together the bits required to use
the query interface?
Here's what I have so far:
//Loading repos
Collection<IMetadataRepository> metadataReposList = new
LinkedList<IMetadataRepository>();
metadataReposList.add(metadataManager.loadRepository(new URI(P2SITE),
monitor));
metadataReposList.add(metadataManager.loadRepository(new
URI(SECOND_P2SITE), monitor));
metadataReposList.add(metadataManager.loadRepository(new
URI(THIRD_P2SITE), monitor));
//Querying
IQueryable<IInstallableUnit> allMetadataRepos =
QueryUtil.compoundQueryable(metadataReposList);
Set<IInstallableUnit> toInstallOrUpdate = allMetadataRepos.query(
QueryUtil.createIUAnyQuery(), monitor).toUnmodifiableSet();
Now suppose I've got two Features I want to use as a root to search
from. I know I need a traverse query, and I can see how to run a
query against an IQueryable, but I'm not sure how to pass my two root
Features in as arguments. Or am I asking the wrong question?
Thanks in advance,
Dave
On Fri, Dec 10, 2010 at 8:35 AM, Thomas Hallgren <[email protected]
<mailto:[email protected]>> wrote:
On 2010-12-09 23:21, David Orme wrote:
Hi all,
I'm trying to execute a P2 query that can chase down all IUs
resulting from starting with several features and traversing the
tree of IUs and included features until all dependencies are
satisfied.
I found the example of how to construct such a query at
wiki.eclipse.org/Query_Language_for_p2
<http://wiki.eclipse.org/Query_Language_for_p2>, but can't work
out how to run it against a set of inputs.
It seems that I need an IQueryable to execute against and some
way to specify the set of Features to use as roots.
I've got an IQueryable, (and can successfully createIUAnyQuery()
against it), but haven't been able to work out how to extend this
to query for the subset that is reachable from a set of Features
that are being treated as roots and are available via the IQueryable.
Any pointers to code snippets or anything else would be welcome.
The simplest query from the wiki looks like this:
$0.traverse(parent | parent.requirements.collect(rc | select(iu |
iu ~= rc)).flatten())
It expects a collection (i.e. your set of roots) as it's first
argument. You then apply it to your IQueryable.
In the expression, 'parent' is the variable holding each item from
the roots. The expression compares all iu's from your IQueryable
with the requirements of the 'parent' and this results in new
instances that will become 'parent' as the query traverses
recursively.
HTH,
Thomas Hallgren
_______________________________________________
p2-dev mailing list
[email protected] <mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
