Re: Mixing P/R philosophy with OO (within J2EE).

Harry <simonsharry> writes:
> On Apr 14, 6:16 pm, Patrick May <p...@spe.com> wrote:
>> On April 7, 2007, Harry wrote:
>> >> My current understanding is that the RDBMS is a layer [ . . . ]
>> >> providing me a very valuable, a very significant service in terms
>> >> of something (set theory) that I'm well familar with since my
>> >> pre-college days. In absence of any multi-vendor-RDBMS support
>> >> requirement, I'd very much like my solution to be closest to this
>> >> layer.
>>
>> You have yet to explain ...
>
> You seem to fail to get the point again and again. That tells me
> you're either plain dumb, or just pretending to not get it... in
> either of which cases no one can really help.
>
>>> why you'd like to always map your problem
>> domain model to a relational schema. You have also failed to explain
>> how RDBMSs being based on relational algebra translates to value in
>> real world problem domains.
>
> Re-read this thread from the beginning, this time a little slowly.

In other words, you've got nothing. Thanks for playing.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

On Apr 17, 8:14 am, Patrick May <p...@spe.com> wrote:
> In other words, you've got nothing.
Not quite...

On Apr 12, 10:19 am, "Harry" <simonsha...> wrote:
> You have very skillfully converted my stance on the P/R style (mind
> you: not just R but *P*/R... PEEEEEEEE-R) into SQL-/-Relational-only.
> You have more than once challenged one or more of us on whether 'this'
> or 'that' can be handled in SQL [only]; I don't believe I or anyone
> has ever suggested that!
>
> My thesis in this thread has consistently been: P/R is sufficient to
> build any enterprise class system (regardless of end-user latency and
> performance contraints).
>
> However, OBs (object bullshitters) like yourselves continuing to imply
> one way or the other that PEEEEEEEE-R is *fundamentally* lacking
> something that OO provides. And, all I'm asking you is to provide one
> counter-example of something that cannot be done in PEEEEEEEE-R to
> deliver an enterprise class system with your choice of latency and
> performance constraints. You can go ahead and up your customer's max
> latency constraints by 1000 times.
>
> By dropping in real-world latency and performance constraints in what
> I'd call mostly a P/R vs OO discussion, you have proven that you were
> (and continue to be) sucked in by the following OO myth.
> Myth: OOP makes programming easier and *faster*.
> [ Source:http://www.geocities.com/tablizer/oopbad.htm]

Harry <simonsharry> writes:
> On Apr 17, 8:14 am, Patrick May <p...@spe.com> wrote:
>> In other words, you've got nothing.
> Not quite...

[ irrelevant blather snipped ]

I repeat, you have yet to explain why you'd like to always map
your problem domain model to a relational schema. You have also
failed to explain how RDBMSs being based on relational algebra
translates to value in real world problem domains.

You made both those claims, I'd like to understand the reasoning,
if any, behind them.

Let's make each question very clear. First, why do you want to
always map your problem domain model to a relational schema? Have you
never encountered a problem domain that isn't a good match for such a
schema? Do you see no value in domain specific languages, for
example?

Second, how exactly does the fact that RDBMSs are based on the
mathematical foundation of relational algebra translate to value in
real world problem domains? It may well do so, but I hear people
making the claim that "Relational is based on math." as if the
benefits were self-evident. They aren't, any more than Common Lisp
being based on lambda calculus automatically translates to development
benefits.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

> > The SQL statement below will give you the information you need.
>
> > select tradeid, pre_tradeid, connect_by_iscycle, connect_by_isleaf
> > from precondition
> > start with tradeid=?
> > connect by nocycle prior pre_tradeid=tradeid
>
> You seem to be making some implicit assumptions here. Let's try
> to make everything explicit. The tables of interest, very simplified,
> are:
>
> matched_trade
> trade_id -- PK
> party_a -- FK
> instrument_a -- FK
> quantity_a
> party_b -- FK
> instrument_b -- FK
> quantity_b
> (In reality, more than two counterparties are supported.)
>
> position
> party -- FK
> instrument -- FK
> quantity
> (Parties have many positions. In the real system, positions are part
> of ledgers.)
>
> settlement_constraint
> party -- FK
> trade_id -- FK
> pre_trade_id -- FK
>
> (This is a gross simplification, but shows that a party may specify
> zero or more trades that must settle before or simultaneously with
> another trade. In this schema, pre_trade_id represents one of the
> trades that must settle before the trade represented by trade_id may
> settle.)
>
> When a new matched trade is received, it is inserted the
> matched_trade table and any constraints are inserted into the
> settlement_constraint table. At that point, the settlement system
> must create a directed acyclic graph of trades and composite trades by
> aggregating any cycles in the simple trade graph into composite
> trades. (Note that there may be cycles within cycles.)
>
> When the DAG is available, the settlement system uses it and the
> positions to determine the topmost node that has a non-negative total
> balance in all instruments. That is, it finds the node in the
> hierarchy where the combination of all partys' positions and total
> trades for that node and all dependent nodes allows settlement. If
> even one party lacks sufficient liquidity, all trades in that node are
> blocked and lower nodes are tried. (In the real system, automatic
> loans are used to increase settlement efficiency.)
>
> So, given this more rigorous, albeit extremely simplified,
> description of the problem, how exactly would you do the job of the
> settlement system in SQL?

Nothing in your last specification shows that the original select ...
connect by, wouldn't give you the information you need. If you run the
query and gets leaf nodes that are not cyclic and there the trade is
not previously settled, you can't can't settle this trade (trade A).
You have to wait until new trade registrations arrive, and if trade A
is a dependent on the newly registred trade, you might try to settle
trade A. Finding dependent trades is easly done by a select ...
connect by statement.

When you finally have a precondition result with only cyclic nodes or
settled leafs, you might try to check the liquidity for each part
using some this like this:
select instrument, sum(quantity)
from (select
party, instrument, quantity
from position
union
select
party_a, instrument_a, quantity_a
from matched_trade
where trade_id in (?, ?, ..., ?)
)
group by instrument

The complete solution is obviously i little bit too verbose to show in
a post, but I have showed you that SQL might find hierachial and
cyclic dependecies, and for evaluating liquidity (using sum). Not
using these kind of SQL statements would cause you to write much more
imperative code.

Your key argument seem to be that SQL can't be used in problem
solutions there DAGs are used. This is not true if you use Oracle or
DB2, which do support recursive queries.

The benefits with using SQL is that you don't have to solve a lot of
concurrency and transactional issues, when sharing a state in the
application server, between threads and requests.

/Fredrik

On 17 Apr, 18:21, Patrick May <p...@spe.com> wrote:
> Harry <simonsha...> writes:
> > On Apr 17, 8:14 am, Patrick May <p...@spe.com> wrote:
> >> In other words, you've got nothing.
> > Not quite...
>
> [ irrelevant blather snipped ]

What you snipped out was *not* 'irrelevant blather'!

> I repeat,

And, so do I...

> > OO is first about relevant, realistic modelling of the programming
> > domain in order to reduce the coding complexity. To pararphrase the
> > founders of OO Krysten Nyggard and Ole Dahle, "the purpose of of OO is
> > to simulate or model reality as a machine in order to reduce
> > complexity." (A single software system may involve multple domains,
> > e.g. the business domain and the low graphic driver support code
> > domain.)
>
> A few messages ago, somebody got chewed out by an OO fan for saying
> that "OO is about modeling the real world" (paraphrased). Make up
> your minds, guys. (Both are hard to measure with any objectivity
> anyhow.)

You missed an essential keyword from the above poster: "relevant".
OOD is indeed about modeling real world entities. But that doesn't
mean I'm going to create a class "Person" that contains properties
that are irrelevant to my problem domain, like
"HairOnHeadCount" (unless that really is relevant to the app!). The
official term is "abstraction". Our domain entities are abstractions
of the real world entities; in other words, they only contain data
that is relevant to solving the problems around that entity in our
application.

That means that many attributes that a real person has will not make
it into the model. That also means that I can add other attributes
that are specific to the application to my Person class if I want,
like "GridIndex", or anything else that will assist me in dealing with
the object.

The point of OOD, at least in business apps, isn't to model reality
just for the sake of modeling.

Jordan

Jordan Marr wrote:
> > > OO is first about relevant, realistic modelling of the programming
> > > domain in order to reduce the coding complexity. To pararphrase the
> > > founders of OO Krysten Nyggard and Ole Dahle, "the purpose of of OO is
> > > to simulate or model reality as a machine in order to reduce
> > > complexity." (A single software system may involve multple domains,
> > > e.g. the business domain and the low graphic driver support code
> > > domain.)
> >
> > A few messages ago, somebody got chewed out by an OO fan for saying
> > that "OO is about modeling the real world" (paraphrased). Make up
> > your minds, guys. (Both are hard to measure with any objectivity
> > anyhow.)
>
> You missed an essential keyword from the above poster: "relevant".
> OOD is indeed about modeling real world entities. But that doesn't
> mean I'm going to create a class "Person" that contains properties
> that are irrelevant to my problem domain, like
> "HairOnHeadCount" (unless that really is relevant to the app!).

I thought that was understood. I was simply pointing out a
contradiction in statements by two OO proponents, one who said, "OO is
about X" and the other who said "OO is NOT about X". I was hoping to
prod them into clarification and reconciliation before I bother to
dissect such claims in more detail. That way I don't waste time
debunking a claim that only a fringe OO proponent has. I wish to go
after the majority opinion first (as soon as I figure out what the
hell it is).

> The
> official term is "abstraction". Our domain entities are abstractions
> of the real world entities; in other words, they only contain data
> that is relevant to solving the problems around that entity in our
> application.

So are relational schemas and procedural modules. If you claim OO is
"more" or "better" abstraction, you need to demonstrate that.

>
> That means that many attributes that a real person has will not make
> it into the model. That also means that I can add other attributes
> that are specific to the application to my Person class if I want,
> like "GridIndex", or anything else that will assist me in dealing with
> the object.
>
> The point of OOD, at least in business apps, isn't to model reality
> just for the sake of modeling.
>
> Jordan

-T-

Please excuse my delay in replying. Real life is interfering
with Usenet.

frebe <frebe73> writes:
>> > The SQL statement below will give you the information you need.
>>
>> > select tradeid, pre_tradeid, connect_by_iscycle, connect_by_isleaf
>> > from precondition
>> > start with tradeid=?
>> > connect by nocycle prior pre_tradeid=tradeid
>>
>> You seem to be making some implicit assumptions here. Let's try
>> to make everything explicit. The tables of interest, very simplified,
>> are:
>>
>> matched_trade
>> trade_id -- PK
>> party_a -- FK
>> instrument_a -- FK
>> quantity_a
>> party_b -- FK
>> instrument_b -- FK
>> quantity_b
>> (In reality, more than two counterparties are supported.)
>>
>> position
>> party -- FK
>> instrument -- FK
>> quantity
>> (Parties have many positions. In the real system, positions are part
>> of ledgers.)
>>
>> settlement_constraint
>> party -- FK
>> trade_id -- FK
>> pre_trade_id -- FK
>>
>> (This is a gross simplification, but shows that a party may specify
>> zero or more trades that must settle before or simultaneously with
>> another trade. In this schema, pre_trade_id represents one of the
>> trades that must settle before the trade represented by trade_id may
>> settle.)
>>
>> When a new matched trade is received, it is inserted the
>> matched_trade table and any constraints are inserted into the
>> settlement_constraint table. At that point, the settlement system
>> must create a directed acyclic graph of trades and composite trades by
>> aggregating any cycles in the simple trade graph into composite
>> trades. (Note that there may be cycles within cycles.)
>>
>> When the DAG is available, the settlement system uses it and the
>> positions to determine the topmost node that has a non-negative total
>> balance in all instruments. That is, it finds the node in the
>> hierarchy where the combination of all partys' positions and total
>> trades for that node and all dependent nodes allows settlement. If
>> even one party lacks sufficient liquidity, all trades in that node are
>> blocked and lower nodes are tried. (In the real system, automatic
>> loans are used to increase settlement efficiency.)
>>
>> So, given this more rigorous, albeit extremely simplified,
>> description of the problem, how exactly would you do the job of the
>> settlement system in SQL?
>
> Nothing in your last specification shows that the original select ...
> connect by, wouldn't give you the information you need.

Your original SELECT statement was:

select tradeid, pre_tradeid, connect_by_iscycle, connect_by_isleaf
from precondition
start with tradeid=?
connect by nocycle prior pre_tradeid=tradeid

None of connect_by_iscycle, connect_by_isleaf, and precondition are
available in the simplified schema I described. How would you get
those attributes from that schema?

> If you run the query and gets leaf nodes that are not cyclic and
> there the trade is not previously settled, you can't can't settle
> this trade (trade A). You have to wait until new trade
> registrations arrive, and if trade A is a dependent on the newly
> registred trade, you might try to settle trade A. Finding dependent
> trades is easly done by a select ... connect by statement.

What is this "easy" statement, based on the schema I provided?
One of the many issues in attempting to map this to the relational
model is that the trade may have multiple dependencies from both
parties.

> When you finally have a precondition result with only cyclic nodes
> or settled leafs, you might try to check the liquidity for each part
> using some this like this:
> select instrument, sum(quantity)
> from (select
> party, instrument, quantity
> from position
> union
> select
> party_a, instrument_a, quantity_a
> from matched_trade
> where trade_id in (?, ?, ..., ?)
> )
> group by instrument

How would you find the node in the DAG that is both capable of
settlement and closest to the top of the DAG?

> The complete solution is obviously i little bit too verbose to show
> in a post, but I have showed you that SQL might find hierachial and
> cyclic dependecies, and for evaluating liquidity (using sum).

You're not quite there yet.

> Not using these kind of SQL statements would cause you to write much
> more imperative code.

Without a working example of how to do this in SQL, that
statement is unsupported. In fact, the code to do this in production,
written in C++, is quite straightforward. Detecting cycles,
aggregating nodes, and checking settlement criteria recursively from a
given node takes very little code. A language with better support for
graphs would make it even easier.

> Your key argument seem to be that SQL can't be used in problem
> solutions there DAGs are used. This is not true if you use Oracle or
> DB2, which do support recursive queries.

My position is that not all solutions map equally well to all
implementation models. Some solutions can be easily implemented using
the relational model. Others, such as this one, map more easily to
other approaches.

> The benefits with using SQL is that you don't have to solve a lot of
> concurrency and transactional issues, when sharing a state in the
> application server, between threads and requests.

RDBMSs are not the only technologies that can provide those
benefits. Good engineering requires that the benefits of a solution
be balanced against its drawbacks and that alternatives with better
cost-benefit ratios be considered. Automatically reaching for an
RDBMS is not good engineering.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

On Apr 22, 9:10 am, Patrick May <p...@spe.com> wrote:

> > Nothing in your last specification shows that the original select ...
> > connect by, wouldn't give you the information you need.
>
> Your original SELECT statement was:
>
> select tradeid, pre_tradeid, connect_by_iscycle, connect_by_isleaf
> from precondition
> start with tradeid=?
> connect by nocycle prior pre_tradeid=tradeid
>
> None of connect_by_iscycle, connect_by_isleaf, and precondition are
> available in the simplified schema I described. How would you get
> those attributes from that schema?

If effeciency is paramount, then you will probably have to modify the
schema to tune to the effeciency bottleneck to some extent. This is
fair because you are comparing it to a *custom made* structure, which
can be whatever it wants.

(I am not that familiar with Connect By, so I will not comment on
frebe's query design.)

-T-