[Dbix-class] FYI: Muldis D code example, 2008 April 30 edition

Darren Duncan darren at darrenduncan.net
Tue May 6 04:24:48 BST 2008


David E. Wheeler wrote:
> On May 1, 2008, at 01:13, Darren Duncan wrote:
>> The example program will create a temporary depot/database, install a 
>> stored procedure in it, and invoke that stored procedure.  The stored 
>> procedure will prompt the user to enter details for 3 people, 
>> specifically their names and addresses, which it will store in a 
>> relvar/table.  It will then prompt the user to enter a person's name 
>> to search for, look for a matching person's details in the 
>> relvar/table, and then inform the user of that person's address.  Note 
>> that for brevity this example program is naive does not check that the 
>> search name actually matched 1 person, and simply tries to use the 
>> result, meaning it will die if that expectation isn't met; a real 
>> program would do more testing.
> 
> Well, that's completely over *my* head. I'll have to see if I can sneak 
> into your talk at OSCON somehow…

Since posting that, I also realized / determined something else about the 
language.  Though it would lack some strictures, Muldis D as already 
defined (sans being able to define data types) actually will already let 
you define persisting databases (except that the detail of where to put the 
dbms connect string or file name is missing, easily fixed).  Due to the 
lack of strictures / type defs, a persistent database is just a tied global 
tuple-typed variable, and you can add or drop tables simply by assigning to 
that tuple-var a new value with more or fewer attributes.  In Perl terms, 
it is like a tied Hash where each key-value pair is a table name and table 
data, and you add/remove tables by just inserting new keys or removing them 
from the Hash.  And so, defining a database schema in Muldis D is really 
just defining a constraint saying what tables you can have and what form 
they must take, rather than being a necessary precondition for having the 
persisting tables at all.  This self-revelation also gave me the solution 
to the chicken-and-egg problem regarding making a generalized in-situ (no 
extra temp variable/table) SQL ALTER TABLE work, since you can't in Muldis 
D do a type/schema change and user data change simultaneously; the solution 
is to relax the constraint of the old schema, change the data, then enforce 
the constraint of the new schema, all of which still atomic in a 
transaction wrapper.  That said, having these constraints is very important 
for industrial-strength apps, and they should be added to the language 
within days, and I should hopefully have a working partial implementation 
in a week.  And then that will make for a more interesting demo. -- Darren 
Duncan




More information about the DBIx-Class mailing list