I use standard templates for a great deal of my code. I have domains, triggers, views, tables etc.
Now, lets forget the lack of support for database triggers (on connect, on transaction etc) and just look at standard items.
When I define a domain, it may depend upon the existence of a procedure, table or view.
So, before I can define a domain, the procedure, table or view, must exist in the database.
Those objects may in turn depend upon the domain being defined.
In order to script this sort of dependency, there is a specific order of create and alter statements that must be followed and the datamodeller does not follow that procedure, so the scripts that are generated all have to be edited by hand before they can run.
In addition, there is no way of diagramming the various dependencies as the data modeler has no method of representing other types of database objects within the diagram.
Here is a perfect example.
I have a firebird database. It has a series of views defined within it. It has some local UI preference tables and a single table that details how the database is to connect to the rest of the data cloud.
When you perform a select upon a data table, it gets it's data from a stored procedure, that stored procedure looks up where the data is that the user is requesting and connects to a remote database that holds the actual data. The insert/update/delete triggers on the view also connect to stored procedures that perform the appropriate action on the remote database. There are also rules that define what to do if the remote database becomes unavailable, rules on connecting to another database and replaying any transactions that did not get replicated before the disconnection, including rules that perform reconciliation of transactions that may occur due to the database being/operating offline for a period of time.
Now, the aspects of security, logging, replication etc all being handled inside the database stored procedure language and triggers, are all standard templates of code that are effectively just a library that is common across multiple databases and can be manipulated/generated by the system.
On top of that, standard data structures for accounting, communications, security etc are all possible as templates, but due to the amount of dependent code that is required to have them properly separate the OLTP and OLAP functionality are not possible to adequately diagram/document with the data modeler as it currently stands.
Is that clear? I can go into more detail if you wish.