Re: Merging beans for composite search
- From: "Francesco Vivoli" <f.vivoli@xxxxxxxxx>
- Date: 22 Jul 2005 01:21:30 -0700
H. S. Lahman wrote:
> Responding to Vivoli...
>
> This sounds like you need to organize your compound criteria into a data
> structure where you can easily access (iterate over) the minimum sum of
> products. For example, a tree with the ORs all at the root:
>
Ok this structure is sound but I'm not able to figure how to use it
(see below)
> [OR]
> |
> +-----------+------------+
> | |
> [OR] [AND]
> | |
> +--------+--------+ +------+----------+
> | | | |
> [Age > 22] [Name = XYZ] [YOB > 1938] [City = London]
>
> P1 P1 ----------- P3 --------------
>
> The minimum sum of products is {P1, P2, P3} and the compound criteria is
> satisfied if any one of the products evaluates to TRUE. So your bean
> "walks" the leaves of the criteria tree in order of boolean products and
> evaluates each product's criterion against the People in hand.
Ehm...I've some problem here understandig what you mean with
"and the compound criteria is satisfied if any one of the products
evaluates to TRUE"
and
"and evaluates each product's criterion against the People in hand."
I think (but maybe I just didn't understand your reply:P) that the
misunderstandig arise since I didn't post the whole specs for this
search, so I 'm going to try writing them more precisely.
------------------------------------
-The search is composed of N Searches, to be executed in an ordered way
-Each Search S_i (i=1...N) is a compound of 1 or more subsearches (this
was the case I was posting originally) S_{i,j} j=1...J_i
-The execution of S_{i,j} and of the S_i follow the following rule:
1 if S_{i,0} returned an empty set => skip to S_{i+1}
2 if S_{i,0} returned a single record => this is the result
3 if S_{i,0} returned a result set S0 (|S0|>1) => execute S_{i,1} over
S0
4 for every S_{i,j} called
5 if S_{i,j} returned an empty set =>stop and accept the
previous
result( S(j-1) )
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)
-------------------------------------
this is the procedural description that I'm trying to avoid since there
are going to be changes/additions in the future.
The case I was posting earlier refers to line 7 where I have the search
criteria of S_{i,j} and I want to narrow the search using the one of
S_{i,j+1}.
So the tree-like structure of each S_i would be flat that is (C is the
criteria of the search S):
-----------[OR]----------------
| | |
C_{i,0} ... C_{i,J_i}
wouldn't it?
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.
> Is this a subclassing relation? If so I don't understand how
> PeopleSearchCriteria IS-A People. They seem like two entirely different
> things.
>
Well actually PeopleSearchCriteria IS a People in the sense that it
only contains logic to map the class People to an Oracle datatype (is
an O/R mapping done by hand); thus really queries are done using
People's attributes.
I'm not really sure having been clearer than before, really...
Cheers,
Francesco
.
- Follow-Ups:
- Re: Merging beans for composite search
- From: H. S. Lahman
- Re: Merging beans for composite search
- References:
- Merging beans for composite search
- From: Francesco Vivoli
- Re: Merging beans for composite search
- From: H. S. Lahman
- Merging beans for composite search
- Prev by Date: Re: OO Design induces an existential crisis
- Next by Date: Re: This stuff is too simple
- Previous by thread: Re: Merging beans for composite search
- Next by thread: Re: Merging beans for composite search
- Index(es):
Relevant Pages
|
