Project

General

Profile

Feature #2135

make FindMany and FindOne return art::Ptr for the found products

Added by Brian Rebel over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Navigation
Target version:
Start date:
11/10/2011
Due date:
% Done:

100%

Estimated time:
Scope:
Internal
Experiment:
-
SSI Package:
Duration:

Description

It would be useful for FindMany and FindOne to return the art::Ptr for the found objects so that associations can be built up from previous stored associations. For example, Clusters are associated with Hits and Tracks can be associated with Clusters. It would be great to then make the association of Tracks to the Hits using the Cluster to Hit association as an intermediary.

History

#1 Updated by Walter E Brown over 8 years ago

  • Category set to Navigation
  • Status changed from New to Accepted

#2 Updated by Christopher Green over 8 years ago

  • Status changed from Accepted to Assigned
  • Assignee set to Christopher Green

#3 Updated by Christopher Green over 8 years ago

  • Status changed from Assigned to Feedback

After preliminary analysis, some decisions are required.

With the current implementation of the FindOne and FindMany query objects, there is information loss: what is stored are the pointers to the elements of the B collections corresponding to the A objects specified. If one wants to have Ptr returned rather than const pointer, we are constrained to save Ptr in the query objects, an increase in in-memory footprint for the query objects by a factor 3.5 (1 pointer -> 2 pointers + 2 shorts + an unsigned long). In addition, if we do not cache the pointers for fast access then access to the pointers only will involve dereferencing a Ptr (a litle slower) plus on-demand product resolution.

So, there several ways forward, each with its own tradeoffs:

  1. Query objects to store Ptrs internally and return bare pointers by dereferencing when requested, with on-demand resolution.
  2. As 1, but with forced Ptr resolution at query object construction time.
  3. As 1 or 2, but with caching of bare pointers (x4.5 over current solution, vs x3.5 without caching).
  4. Retain the current, "lightweight" query objects and inaugurate two new classes conforming to 1, 2 or 3 above.

Opinions?

Thanks,
Chris.

#4 Updated by Brian Rebel about 8 years ago

After discussions with Chris, it seems that the solution involving making new classes to do 1 or 2 above is the best option.

#5 Updated by Christopher Green about 8 years ago

  • Status changed from Feedback to Resolved
  • Target version set to 1.00.07
  • % Done changed from 0 to 100

New classes FindOneP and FindManyP have been implemented with the desired functionality.

#6 Updated by Christopher Green about 8 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF