At 5:31 AM +0100 8/31/06, Nigel Hamilton wrote:
Rather, the proposal is focusing on what users of these data structures
would / could see. The idea is that relational structures have the same
ease of use and flexability that things like hashes or arrays or sequences
or sets do now. They can of course just be stored in RAM like the
aforementioned, when the working set of data is appropriately small, but
just as a hash-doing class can have a disk-tied implementation as well,
for scalability and/or persistence so can a relation-doing class. And
this is one main reason why Relation etc is a role rather than a class, so
people can choose how it works.
OK. I can see that a tied-relation could help solve the talking to
disk problem. But I wonder about some of the other RBMS things on
offer - locking, indices etc? Some of these features are there to
assist with getting data efficiently to and from the disk. Although
they are not artefacts of the relational model they are important
parts of what makes a database work. Could your relational model be
"tied" to an existing physical database?
NIge
Yes it could.
First of all, note in my explanation that I mentioned indices
already, as examples of "non significant" (non value affecting) extra
data that an object could hold or be tied to; these can be stored on
disk and/or in memory as is appropriate.
Next, the Software Transactional Memory concepts / interfaces in Perl
6, such as the concept of atomic code blocks or routines, would be
mapped to ACID features of a disk store; the start of an atomic
operation is like a "start transaction" and the successful completion
of one is a "commit"; a retry or fail involves a "rollback" etc.
Note that a proper system will need to (or will ideally) support
nested transactions, so any given atomic block won't have to know
whether it is inside another one or not to be itself atomic.
As for locks, the Perl 6 interface / functionality for managing
shared data between multiple threads or processes would map to
appropriate locks or other mechanisms on disk where applicable.
Truly, a database was never supposed to be a world separate from an
application; as I recall, Cobol or something introduced the idea of
databases and applications being at arms length, and it stuck, but
that isn't the way things should be; how they should be is
integrated, or at least to the point that a generic reusable module
within an application is integrated; eg, DBM or BDB; also, the
concept of servers is orthogonal to this; anything can be relegated
to a server. Using the DBM analogy, what I propose is that the
relational analogy of an in-memory Hash is built-in to Perl, and any
extensions that make it tied to something external like a disk be
language extensions / CPAN modules; all Perl 6 iteself has to do is
make it easy to attach such extensions, and I think it more or less
does so, save edge cases to hash out.
-- Darren Duncan
