I'd like to compose a query to use with DgnECManager.FindInstances using an ECQuery. Unfortunately, the MstnPlatformNet documentation continues to ignore that class. The SDK examples help little, using the catch-all SelectAllProperties.
DgnECManager.FindInstances
ECQuery
SelectAllProperties
ECQuery query = new ECQuery(GetSearchClasses()); query.SelectClause.SelectAllProperties = true;
How can one write a query, say, to select Item instance properties having a certain value? That is, I'd like to know about ECQuery.SelectClause. If Item Types supported SQL, I would write something like...
ECQuery.SelectClause
SELECT * FROM MyItemType WHERE ID='abc'
Since DgnECManager.FindInstances returns IQueryable<> it's tempting to ignore the MstnPlatformNet API and use LINQ to compose a query. Which approach would you make your strategy?
IQueryable<>
That is an information, not question ;-)
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
My session was interrupted; you're too quick off the mark!
Regards, Jon Summers LA Solutions
ECQuery supports all that kind of stuff and more...I don't know why it's apparently not present in the MstnPlatformNET docs. Perhaps there's a separate ECFramework docs? Perhaps Robert Hook knows?
Paul Connelly said:ECQuery supports all that kind of stuff and more
What does ECQuery.SelectClause do internally? Does it perform more efficient selection and sorting than using LINQ after GetInstances?
GetInstances
Hi Jon,
Jon Summers said:Does it perform more efficient selection and sorting than using LINQ after GetInstances?
I do not know how exactly ECQuery is implemented (but a study of ECquery assemblies code provides some insight and ideas), but I think LINQ will be far slower ... because LINQ is always slow (especially when there is no knowledge how LINQ works internally and queries are not implemented in a right way and cannot be optimized internally)
My assumption is:
When ECQuery with criteria is used, formalized query is passed to native API and processed very close to DGN data. It means the search is fast and only limited amount of data is returned back to native API.
When LINQ is used to posprocess, evaluate and filter results from ECQuery, possible all data have to be passed (and marshalled) to managed API and even when optimizations like lazy instantiation (known from e.g. Entity Framework) will be used, to evaluate conditions and filter elements, the elements (and EC classes and any other data) have to be instantiated in NET (memory intensive) or marshalled from native to managed (processor intensive).
With regards,
Jan
Ok, after some testing, this code seems to work:
FindInstancesScope scope2 = FindInstancesScope.CreateScope(Session.Instance.GetActiveDgnFile(), new FindInstancesScopeOption(DgnECHostType.All, false)); IECSchema ecSchema = DgnECManager.Manager.LocateSchemaInScope(scope2, "DgnCustomItemTypes_MasterPlanner__x0020__", 1, 0, SchemaMatchType.Latest); string[] ecClassesNames = { "Something" }; var query2 = QueryHelper.CreateQuery(ecSchema, ecClassesNames); QueryHelper.WherePropertyExpressions(query2, "ID", RelationalOperator.EQ, 1); query2.SelectClause.SelectAllProperties = true; var result2 = dgnECManager.FindInstances(scope, query2);
As usually, you have to iidentify / locate:
I recommend to read a description of QueryHelper.WherePropertyExpressions method (not in help, but in xml file), because conditions/prerequisities are described here.
P.S. Please don't ask such questions! After initial thinking "it's really interesting question, it would be nice to know also" and some playing with code ... a half of a day is just missing :-))))
Jan Šlegr said:I think LINQ will be far slower
Perhaps. But far slower beats can't implement using ECQuery!
Jon Summers said:But far slower beats can't implement using ECQuery!
Try it. Measure. ;-)
More options are (nearly) always available with own pros and cons.
The problem of LINQ is that it's slow by its nature (sometimes a difference from optimal solution is minor, but easily can be huge), unfortunately in the discussed situation LINQ represents wrong approach not because of its feature, but because it's requires to collect all data, pass them to managed API and evaluate/filter them later, which is really inefficient in my opinion.
It seems not all options of native API are available in managed world, but it's alwyas possible to implement everything in native API and to pass results only to managed code using C++/CLI.
Regards,
Jan Šlegr said:I recommend to read a description of QueryHelper.WherePropertyExpressions method (not in help, but in xml file)
Unfortunately...
<member name="M:Bentley.EC.Persistence.Query.QueryHelper.WherePropertyExpressions(System.Collections.Generic.IList{Bentley.ECObjects.Schema.IECClass},Bentley.EC.Persistence.Query.WhereCriteria,System.Object[])"> <summary>Private implementation method.Search all classes in query
We need public methods!
public
Jon Summers said:We need public methods!
There is a public method and its description is available in XML file as well. Or do you think my code above does not work despite of I wrote it works, because used method is private? ;-)
And Visual Studio provides clarification one from overloaded methods is available: