RE: Locking records in DB2

> From: Paul Holm
> 
> You are right, we have wondered off the thread of concurrency into OO
> application design so I'll stop with these thoughts.

Well, before you stop, you might want to address the point I've made
repeatedly, which is that your design does not support multiple
independent field groups.  What will you do to fix that?


> I think you may have made some premature assumptions.  Multi table
Rows
> can
> be updatable.   A JoinedRow has fields from multiple tables and the
same
> process applies for each table.  We require primary keys for all files
be
> present in the JoinedRow.

I haven't made ANY assumptions, because I'm talking basic application
design.  You're the one who keeps talking about your product.  That
might be why we get hung up, because I'm talking about basic
architecture while you're defending your design decisions.

My issues are based on my experience over the years.  For example, I can
immediately see that your system doesn't support multi-row edits.  For
example, a bill of materials may require that based on the item class,
one and only one ingredient must be defined as a co-product.  A
row-level validation doesn't work here.  There are dozens of other
examples in the real world that just don't fit nicely into a simple
field- and row-level edit paradigm.

Again, that being said, OO frameworks can be designed for applications
with less demanding editing requirements, and I'm sure you do that fine.


> Validation typically falls into generic and custom validation.
Generic
> validation is done automatically and custom validation  (multi table
cross
> validation) is accomplished using subclassing and overriding the Row's
> validate method as is commonly done in frameworks.  This frees the
> programmer of all the reoccurring validation and they only need to
code
> for custom validation.  This has been a huge time savings for us and
> scales from small simple applications to large complex applications.

Again, as with any framework, the applicability of the solution depends
directly upon the designer.  With a static problem set like HTML
generation, OO is quite handy.  However, business is more about
exceptions than rules, and in the OO world exceptions tend to be very
hard to handle.  You talk about subclassing, but that only works if the
parent class was smart enough to allow a given task to be subclassed.
If the framework designer didn't foresee some business need, then the
framework won't be any good without serious changes.

That's why I prefer procedural languages for implementing real world
business logic.  Since real world conditions are messy, and complex, and
often change from day to day, the rigid nature of strict OO hierarchies
tend to work against them in reacting to real business environments.


> I agree performance needs to be designed in as well.  In addition,
> internally and also from a customer point of view, time is money, so
we
> have to develop with designs that yield high productivity, perhaps
that
> is where our opinions differ.  We will take productivity and
> flexibility and good performance over a cycle here or there.

I wasn't talking about a cycle here and there.  I was talking about
orders of magnitude in code executed.  If you have just 10 50-character
Strings, you are talking about 500 times the amount of code to compare
two records (not to mention all the overhead of iterating through the
field list, checking the class, and so on).  This is on every update.
Hardly chicken feed.  If you conside this "a cycle here or there", and
if you're willing to make design decisions that result in 500 times the
code executed, then you're going to end up with some pretty poorly
performing programs.

On the other side of the coin, a good skeleton with a decent programmer
is can code quite quickly.  We're talking about perhaps costing a few
hours of developer time as opposed to adding huge amounts of unnecessary
overhead to the runtime.  Ask any end user which way they would want you
to decide.

Joe