Sorry about being a few days behind the times on this thread. Things got
busy, and then I hit the road and now I'm in Silly Valley. (The two are
not unrelated.)
Two things jumpped out at me over the course of the thread.
Dave Rolsky said:
> Ideally, the database should handle referential integrity so that you can
> use the database from multiple languages/apps/whatever without having to
> duplicate the referential integrity maintenance code.
In reply, Stephen Adkins replied:
> If we relied on referential integrity capabilities enforced in the
> database, how would our application be portable to MySQL?
> Files? BerkeleyDB? Remote data stores accessed via SOAP?
> Repositories on legacy data storage? Real-time data collected
> from the operating system?
I agree with both of these points, but I wonder if their juxtaposition
suggests that we need to consider the domains of applicability of p5ee
(or portions thereof) more carefully. (Or maybe I just do -- no doubt
everyone else is up to speed. :-) )
Looking at Stephen's examples, I have to wonder: if you're using files,
do you have a right to expect transactions and other forms of referential
integrity? Do you have a place to call your application "enterprise"?
One way of looking at the problems suggested here is that "you must be
at least this clueful (or at least feature-ful) to ride." That is,
*don't* use files. If you're going to use MySQL, you *must* use
Innodb tables and take advantage of their transactional features.
Another way of looking at it is simply a comparison of apples and oranges.
Do the concepts of referential integrity and real-time data collected from
operating systems really map onto each other? It seems to me like the
mapping between the two might be so tenuous and require so much duct-tape.
I agree that portability is a desirable goal, but to me that means that if
you have an apple then you can port your application to another apple, but
not to a chocolate-covered banana (let alone the European currency system).
:-)
From a practical / coding point of view, I wonder what p5ee can do to
make handling this impedance mismatch as easy as possible for coders.
I wonder if a DBIx::AnyDBD approach might make sense here. That is,
a layer may be provided that will provide the right hooks for people
to create the kinds of referential integrity that are appropriate to
their environment. If this happens to include a DB in the background
that has all that good stuff, then that layer might, modulo only a small
bit of programmer pain, "return true" and be done with it. But for
environments with something in the background that *doesn't* take care
of RI for you, the layer will "return false" by default and crash your
application. This will get your attention, you stack-trace the problem,
and realize, "oh, here's where I'm suppose to code my own RI scheme."
And then you go to it. (One would hope that one would know about this
issue before the crash brings it to ones attention, of course.)
As p5ee matures, no doubt classes and class hierarchies within this layer
will be built up that cover most common cases of RI with regards to things
that aren't really up to handling RI by themselves. (e.g. CSV files, BDB and
similar, MySQL MyISAM tables, etc.)
Cheers,
Richard
--
----------------------------------------------------------------------------
Richard Dice * Personal 416 841 7365 * Fax 416 841 7364
ShadNet Creator * http://shadnet.shad.ca/ * [EMAIL PROTECTED]
Occasional Writer, HotWired * http://www.hotwired.com/webmonkey/
"squeeze the world 'til it's small enough to join us heel to toe"
- jesus jones
