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
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
