You can look at acs-content-repository/sql/postgresql/content-type.sql
content_type__trigger_insert_statement and a few functions below it. What it does is when you insert to a view like cr_fooi. It fires up the trigger and calls the __new etc.
Its similar to calling the __new functions but it does so during a insert event on the view.
I guess what is Jeff is suggesting if we can make use of this on other object types as well. I think Don is looking at this too, DanW also indicates in the code that further testing needs to be done.
Regarding your query writer. What does it do? Does it write for you the sql on a file. So you have a template to follow. Or it uses its own thing, wherein it writes the query on the fly? Sorry that I have to ask this questions? (I am coding in CCM so its hard for me to follow on OACS, also my comparison of both platform, so sorry if I compare it too much).
Some points I would like voice out of QW. I hope they are valid.
- hopefully QW will enable support for custom queries when needed. Automation is good but hand tweaking is needed sometimes.
- but if hand editing is needed, how can QW follow the hand edits?
- not all cases we need to abstract the query. Or maybe the point is. Instead of abstracting in the sql layer like content_item__new. Why not just tcl proc that calls. content::item::upload. Maybe its not the query writer scope, don't know.
- Easness of using the db with a complex data model is double edged. On one hand good developers can work faster, on the other hand poor developers can create poor code faster. Or maybe poor developers can now code and make it really poor in terms of SQL performance.