Re: Merging beans for composite search

H. S. Lahman wrote:
> Responding to Vivoli...
"and evaluates each product's criterion against the People in hand."

> I think I may have misunderstood your problem. I thought you had a
Yes, my first post really wasn´t complete...


> > 5 if S_{i,j} returned an empty set =>stop and accept the
> > previous
> > result( S(j-1) )
>
> If I understand this, you will accept a subset of tuples for a more
> general criteria if none of the members satisfy the more specific
> criteria, right?
>
yes


> > 6 if S_{i,j} returned a single record =>accept this one
> > 7 if S_{i,j} returned S(J), |S(j)|>1 =>execute S_{i,j+1} over
> > S(j)
> >
>
> If I understand this correctly, the overall goal is to extract a single
> tuple based on a hierarchical suite of rules for pruning multiple
> members of subsets...
>

yes

> I don't think of it that way. I see it as more like
>
> [Search]
> |
> +----------+----------+----...
> | |
> [S_1_0] [S_2_0]
> | |
> +-----+-----+--... +------+------+---...
> | | | |
> [S_1_1] [S_1_2] [S_2_1] [S_2_2]
> | | | |
> ... ... ... ...
>
> Each [S_i_j] node has an attribute matching criteria, C_i_j. At each
> node of the tree, one either: (a) descends (multiple tuples pass); (b)
> moves laterally (no passes and J = 0); or ascends (J > 0 and no passes).
> (Obviously, more levels would require more subscripts but the depth
> could be arbitrary.)
>

well, yes. In my sketch I had been lazy, I had to link my root node
actually...


> > The issue here is that this is the runtime structure, which uses a
> > search resultset to determine which action to take next; nevertheless
> > the other part is the istantiation of it: The exact criteria that are
> > loaded depend on which attributes are set in the People object that we
> > are searching on.
>
> I am a bit confused about the phrasing here. This implies there is only
> one [People] object that one already has in hand. So what are you
> actually searching for (i.e., what is the set being searched)?

Yes, I have an istance of People with some attributes set to some
value. The point is that there can be 0,1 or n People istances which
posses these values and this´s what I have to find out. But you had
already answered yourself below:P

> As I understand it now, you have a set of objects, [X], from which you
> would like to select one. You have a hierarchical suite of rules for
> pruning the set. At each pruning node in the hierarchy, the specific
> values to compare to the [X] attributes when checking are determined by
> attribute values in a People object.

exactly

>
> Question: Are the specific attributes of [X] to be checked at each node
> fixed for the node or are they also determined by the attribute values
> of the People object?
No, the point is that the structure is the one you pointed put above,
but the criteria that each node will evaluate are dynamically
determined, that is,
the nodes that are being created and their linkage depend on which
attributes the sample People istance have been set

For example given a sample People p:
if p has surname, sex, date of birth set => I create a node to search
with a criteria that use these attributes.
otherwise this search (and its eventual subsearches) are skipped (the
node is not created)

So I am creating a class hierarchy which allows me to programmatically
create the node structure. Then the real one that will be used will be
formed at run time. I am actually biased toward a rule based system
determine which nodes are to be istantiated.

The only problem with my current solution is that I have not been able
to parametrize the lines 5,6,7 of the above sketch...At some point in
the code
I have exactly the same conditional, but I am starting to think that
there is no really an OO way to express it.
Am I wrong?!


> FWIW, I think this is a real bad habit on the part of O/R mapping and
> layered model infrastructures. It makes life easier for the
> infrastructure implementer but it is not very OO.
>
> A [People] is an abstraction of some problem space entity and it has
> some set of <knowledge> responsibilities. A [SearchCriteria] is an
> entirely different <conceptual> beast that just makes use of [People]'s
> knowledge in some special way necessary to the problem solution. So
> they should be related by association rather than subclassing.
>
>

Yes, I agree. But this is out of my scope of intervention...

> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@xxxxxxxxxxxxxxxxx
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> (888)OOA-PATH

.