Re: Real world issue: How to "split" queries in presence of record replication and replication sensitive aggregate functions ?

pamelafluente_at_libero.it wrote:
> Marshall ha scritto:
> > The term is idempotent. If the binary form of the aggregate
> > function is idempotent, the aggregate will return the same value
> > even if values are repeated arbitrarily. Since + is not idempotent,
> > sum() is "sensitive" to repeated values. Since binary min *is*
> > idempotent, aggregate min() is not "sensitive" to repeated
> > values.
>
> I have been reading the definition of idempotence
> http://en.wikipedia.org/wiki/Idempotent
>
> it says:
> A unary operation (i.e., a function), is idempotent if, whenever it is
> applied twice to any element, it gives the same result as if it were
> applied once: f maps X to X
> f is an idempotent function: f(f(x)) = f(x) for all x,

Yes, I was concerned that someone might confuse binary idempotence with unary idempotence, which is why I specifically used the word "binary" twice in the above paragraph. I'm afraid you'll need to reread the wikipedia entry with this in mind.

> In my case I mean something different (the function is not unary,
> aggregate function
> works on several values).

You're also going to need to understand how binary functions are used to define aggregate functions. Once you understand how binary + relates to sum(), and how min(x,y) relates to aggregate min(), only then will you be able to understand what I'm talking about, and why the correct term for what you're describing is "idempotence."

> In the example I made above, you see that thw first query (that would
> for instance be generated by access gives a wrong result. The second
> one, which would be generated by Business Object, seems a right
> answer).

I'm sorry, but I'm not willing to work through your overly complicated example to try to figure out how to answer your question. If you can produce a minimal example, I would look at it. Maybe something with one table and two column, and maybe two or three rows. Start small, then work up. Don't start big and complicated; that just leads to miscommunication and wasted effort.

Marshall Received on Sat Sep 16 2006 - 17:15:25 CEST