QueryExpressionWithSort clone Cancel The title field is required!

1. Bert Strobbe

   

   19 posts
   Registered:
   25 Oct 2018
   11 Jan 2022

   Link to this post

   We are now using the new QueryExpressionWithSort array that's available on the FetchDataRequest object. We recently had an issue with a developer manipulating the object in the DataAccess.
   In a session without PASOE, he builds a request with a QueryExpressionWithSort, but kept the containing ListQueryExpression for future use. The ListQueryExpression contains a condition on an unexisting (unmapped) field. 
   In the DataAccess he extracts the ListQueryExpression from the QueryExpressionWithSort, because otherwise the resulting query would fail (as the field is unmapped), and uses the extracted expression to do some query magic (for instance join with another table).
   So far no problem, but then the developer decides to delete the extracted ListQueryExpression object.
   Since that object is the same as the one he built for future use, it isn't usable/correct anymore.
   
   We tell our developers to rely on garbage collection, to not delete the objects, but I don't think that's enough. The fact that the QueryExpression objects in the DataAccess can be the same as the ones used by the caller when you don't use PASOE, can cause unexpected behaviour. 
   We believe that it's better that every time the QueryExpressionWithSort is sent through the FetchData method, first a clone or deep copy of that object should be made. 
   
   Does anyone have any ideas on this (apart from not deleting objects from QueryExpressionWithSort)?
2. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   11 Jan 2022 in reply to Bert Strobbe

   Link to this post

   That's a tough one - and I think you can only solve this through coding-standards.
   
   The fact, that the object's (and the sets of objects) are passed around by reference is actually beneficial for runtime performance. The object is only cloned (marshalled) for the purpose of passing it to the AppServer.
   
   IMHO the safe place to keep a copy of the set would be on the client. This is the only place where you as a developer really know, that you rely on the fact that the set that is passed to be backend should be kept sort of immutable. 
   
   

   We tell our developers to rely on garbage collection, to not delete the objects, but I don't think that's enough.

   
   
   This is not really a matter of GC. It's more a matter to trust nobody. If you rely on an object or a set of object remaining unmodified, the fact that the object is unmodified needs to be part of a contract - or you should not give anybody else access to that object (or set of objects).
   
   
   
   
3. Bert Strobbe

   

   19 posts
   Registered:
   25 Oct 2018
   12 Jan 2022 in reply to Mike Fechner

   Link to this post

   If we would keep a copy of the set, it would be nice if there is an easy way to clone ListQueryExpression.
   What would be the easiest way to do that?
4. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   12 Jan 2022 in reply to Bert Strobbe

   Link to this post

   What would be the easiest way to do that?

   
   
   ... get the framework vendor to implement a deep Clone() method on that class.