Instantiate and Query Preservation?

chadstoltzfus

I am attempting to store queries(of edges) in a FeatureScript attribute of parts, and then derive those parts into another context. It seems to not preserve the query when using the instantiate function and I'm guessing that's because opMergeContexts() doesn't go into FeatureScript attributes. Is there a way I can go and merge the contexts of the queries stored in FeatureScript attributes or do I have to do some other kind of workaround? 

lana

@chadstoltzfus
The attributes should stay, I'm surprised if they were lost in opMergeContexts() but the queries stashed in those attributes would not be valid in the context calling merge. Notice that opMergeContexts can accept trackThroughMerge array of queries and return array of corresponding evaluation results after merge. That would be a better way of handling this.

chadstoltzfus

How would I go about getting those queries? I'd imagine I would have to do something like before deriving in the parts, query the parts in the other context (the context of the part studio I am importing) and then get the FS attributes from all of those queried parts, check if they have a query stored in their attributes, and then put those queries in trackThroughMerge. Is there a way to query in a context other than what the current feature is being executed in? 

kevin_o_toole_1

As Lana says, attributes should be preserved in instantiated parts. For instance, qAttributeQuery() should find entities with attributes correctly.

The likely issue you're seeing here is that getAttributes(...{"entities" : oldQuery )) doesn't work because oldQuery doesn't resolve to anything in the new context. That can be solved by replacing oldQuery with a working query (such as a specific qAttributeQuery()), or by passing in oldQuery in the "trackThroughMerge" argument to opMergeContexts, or the "queriesToTrack" option of derive().

To your last question: If you're rolling your own code with opMergeContexts, it's perfectly possible to resolve a query in another context e.g.

const otherContext is Context = somePartStudio.buildFunction(somePartStudio.configuration);
const evaluated = evaluateQuery(otherContext, oldQuery); // or any other evaluation

..but I wouldn't recommend writing code like that for most applications, since the high-level instantiator (or the less-high-level derive()) are easier to work with than low-level code like above.

chadstoltzfus

Right, the attributes are staying, it's just that a query that might be stored in an attribute is not resolving to anything. Like you said the issue I'm encountering is when using getAttributes(...{"entities" : oldQuery )). So when you say replace oldQuery with a working query, I guess what you're suggesting is instead of assigning a query of the edge to the body owning that edge, I should create some kind of attribute pattern that identifies that edge and then query for that edge after importing. Also bear in mind I'm using instantiate and not derive so I don't have a queriesToTrack option available (unless I write my own instantiate).

lana

I also would not recommend switching from use of instantiator to direct call to opMergeContexts. If you can mark the edges you want to access with a special attribute, please do that and use qAtttributeQuery() as Kevin proposed.

MBartlett21

@chadstoltzfus
@kevin_o_toole_1
@lana

I did modify my copy of instantiator.fs a little while ago to enable tracking through the instantiate.
This was so I could track a sketch region through the instantiate (The feature I was using it for is also in the document)
See the link below:
https://cad.onshape.com/documents/2ad339efe44128f5171291fa/w/400f27295a4447ca3ac2d504/e/30d9197c261899fd3f9c28f4

lana

I remembered seeing a user-modified instantiator! That looks correct and seems like it will be useful. Thank you @MBartlett21 ! We should look into exposing this functionality in std.

MBartlett21