The G/Technology runtime environment is great and I haven’t seen much issues with it working at KPN Netherlands from 2009 until recently. A whole different story is the G/Technology developer experience and I’m very frustrated about it :
There’s no clean distinction between development and runtime environment
In G/Technology your feature definitions are stored in the database and made available for clients through a process called ‘metadata publishing’. This process calls some procedures and packages in the database to gather all the information needed, store it in temporary tables called ‘optimized tables’and then writes the content of these tables to a folder as .raw files:
G/Technology metadata folder
This folder then is read runtime and much of the information in the database is not needed anymore. All the tables starting with G3E.., much of the Oracle packages and procedures are only needed at development time, not runtime. In my view this is a clear polution of the database and mixing of concerns. A better way would be to make a clear distinction between a development-scheme and production-scheme and maybe take of all the generating-procedures from the database and store them somewhere else. Visual Studio T4 templates would be an ideal candidate to replace the code generating packages in the database.
It takes to much time to test and debug your features
Back in the days of FRAMME, you had a great tool called ‘Framme Knowledge Based Tools Rulebase Builder’ or FRMKTRB/FRMKTNUC as I recall its product name was, and it essentially was a feature definition generating tool (a rulebase is what you know would call metadata). It would allow you to generate, compile and test your feature definitions fast, easy and in a very user friendly way. The only downside was that it was not multiuser-enabled and it had its own datastore to store definitions. The options you have now for developing your definitions are either one of these :
- The G/Technology project tool
- Metadata explorer from within G/Technology
- Use SQL-scripts
G/Technology project tool
G/Technology metadata explorer
GPT is a good starting point for building new features, but the saved sql generated must be edited to provide logical feature numbers and names. Once the sql scripts have been run in your development schema, changes are easy to make through Metadata Explorer. Having a template script to pull the table data from the development schema allows the feature definitions to be migrated to a QA schema and eventually a production schema. For instance, this sql will generate the insert statement for the G3E_FEATURE table:
select ‘INSERT INTO G3E_FEATURE (G3E_FNO, G3E_USERNAME, G3E_TOOLTIP, G3E_PRIMARYGEOGRAPHICCNO, G3E_PRIMARYATTRIBUTECNO, G3E_DCNO, G3E_PRIMARYDETAILCNO, G3E_NUMBEROFNODES, G3E_IMPORTFEATURENAME, G3E_REPLACE, G3E_NAME, G3E_MERGE, G3E_CLASSIFICATIONANO, G3E_IDENTIFIERVIEW, G3E_BULKEDIT , G3E_ICONORDINAL, G3E_EDITROLE, G3E_SELECTROLE, G3E_DELETEROLE, G3E_RINO, G3E_RIARGGROUPNO, G3E_EDITDATE)
‘ || ‘
VALUES(‘ || G3E_FNO || ‘,”’ || G3E_USERNAME || ”’,”’ || G3E_TOOLTIP || ”’,”’ ||
G3E_PRIMARYGEOGRAPHICCNO || ”’,”’ || G3E_PRIMARYATTRIBUTECNO || ”’,”’ || G3E_DCNO || ”’,”’ || G3E_PRIMARYDETAILCNO || ”’,”’ || G3E_NUMBEROFNODES || ”’,”’ || G3E_IMPORTFEATURENAME || ”’,”’ || G3E_REPLACE || ”’,”’ || G3E_NAME || ”’,”’|| G3E_MERGE || ”’,”’ || G3E_CLASSIFICATIONANO || ”’,”’ || G3E_IDENTIFIERVIEW || ”’,”’ || G3E_BULKEDIT || ”’,”’ || G3E_ICONORDINAL || ”’,”’ || G3E_EDITROLE || ”’,”’ || G3E_SELECTROLE || ”’,”’ || G3E_DELETEROLE || ”’,”’ || G3E_RINO || ”’,”’ || G3E_RIARGGROUPNO || ”’,SYSDATE);’
from G3E_FEATURE
where G3E_FNO in (100, 200, 300)
order by G3E_FNO;