Forum OpenACS Q&A: Re: Will Dr. OpenACS survive? Or why I stopped worrying and learned to love the .LRN consortium?

Andrew, I wouldn't bury so much logic in PL/[pg]SQL for starters. In reality, we can auto-generate packages the include "new" and "delete" functions and as the dynamic types package grows (and gets moved into OpenACS proper as it should, as it becomes integrated better and better) I'm ready to propose we do so and that packages include nothing else.

Why keep "new" and "del"? Because some old code does more than a simple "create supertypeobject/insert params into my type specific table" operation (bad idea, IMO, but that's life). So for such types we need to call "new" so we might as well auto-generate "new" functions for new types.

Anyway ... over time our idea is to move more and more to high-level Tcl APIs for the declaration and manipulation of types.

One thing we won't do, and which will always make query support more "difficult" for us than for frameworks that bury logic in the application layer (generally the object layer) rather than use complex queries, is, well, get rid of those complex queries.

Because as you point out ... using the RDBMS properly as we do aids scalability. The simplistic approach of (say) building a container object containing a list of object info returned by a simple query, that is then filtered by some other set of application object is by its nature, I suspect, less efficient than writing a complex query that returns exactly what you want in the first place.