First, thanks for doing the bind variable emulation, I was unaware of
this and it is a big help.
Regarding inheritance, I was unaware of problems with alter table,
I'll investigate this. If we can't alter table on inherited tables,
we can't use it.
As far as the other stuff goes, I've done a little work investigating
the difficulty of adding a user C routine to find triggers,
constraints, and indices and then issuing SPI calls to create them on
the inherited table. This is now something that is at least feasible
because ACS 4.0 names all constraints in a consistent manner, which
means munging constraint names into something unique based on the
derived table name won't be difficult.
We'd only be using inheritance on acs_objects and derived tables, not
willy-nilly throughout the system.
I don't think performance should be a problem, as selecting from all
inherited tables is in essence a UNION Of simple selects on the table.
This replaces the JOINs needed in the existing ACS Classic 4.0 datamodel.
Interest in inheritance is picking up within the hackers group,
presumably because more and more of SQL92 has been implemented. The
lack of interest has been largely a triage issue, with SQL92
compliance requiring more immediate attention.
Ben and I more or less decided we'd take a shot at trying an
inheritance-based datamodel, and if it appears to be more work than it
is worth, we'll quickly back off and port the datamodel directly.
As far as a timeline goes, Ben's getting started next week. I can't
get started until the week after, though the fact that Dan has done
the bind emulation means my first task is already done (thanks
again!). Dan's starting on the core, too (when, Dan?).
If folks are interested in looking at ACS Classic 4.1's core and a
couple of modules (i.e. bboard) without downloading it themselves, you
can now browse the source via the SDM here at openacs.org.
