Thursday, May 24, 2007

Covalentia Version 2.3: Powered by Oracle

Covalentia may not be as good as other code generators such as Iron Speed etc to have version compatibility, but at least, it’s FREE of charge (since I’ve consumed a lot of other FREE stuffs from the internet, I’d say it’s time to give back to the community). I realize that this is a big issue - whenever Covalentia gets upgraded, migration from the previous version to the latest one is going to be a pain in the ass. But, worry not – we’ll address this issue later on when we come to that stage ;)

I’ve spent tremendous hours trying to include Oracle Database as one of the databases supported by Covalentia. And it ain’t an easy job. Oracle Database has got some limitations compared to other databases such as Microsoft SQL, MySQL and PostgreSQL. Perhaps, this is the reason why it’s faster? No? I have no experience in using Oracle and so I can’t say much about its real performance compared to others. Now, let’s talk about these limitations, and you’ll soon find out why I had to do the changes that I did in the latest release.
  • Renaming SystemTbl table to ConfigurationTbl
    Oracle doesn’t seem to like that name, anything ‘SYSTEM’ is probably a reserved word. So, we have to rename the table to ConfigurationTbl. And while we’re at it, why not remove and add the following items:
    • Remove SystemPath column – put this variable in the web.config file instead and rename it to ApplicationPath.
    • Add a new column – ErrorLogEmail to store the Error Log E-mail address.

  • Renaming of the following tables (and their corresponding primary keys) and stored procedures because Oracle limits the length of identifiers (table name, column name etc) to only 30 characters.
    • UserGroupSubModuleFunctionTypeTbl table to UserGroupSmftTbl
    • UserSubModuleFunctionTypeTbl table to UserSmftTbl
    • DeleteUserGroupSubModuleFunctionTypesByUserGroup stored procedure to DeleteUgsmftByUg
    • DeleteUserSubModuleFunctionTypesByUser stored procedure to DeleteUsmftByU
    • DeleteUserSubModuleFunctionTypesByUserGroup stored procedure to DeleteUsmftByUg

  • Naming convention
    Covalentia uses the following naming convention for tables and columns respectively: TableName and ColumnName
    Oracle (and PostgreSQL), however, doesn’t allow this. Well, not really, you could preserve the case but this will cause some major problems when coding Covalentia as I have to add “TableName”.“ColumnName” here and there (with “) in the SQL queries. So, we have to stick with TABLENAME and COLUMNNAME (all capital case) for Oracle and tablename and columnname (all lower case) for PostgreSQL. As you may already realize that this may cause problems when generating Business Objects, Component and Control classes and User Controls (classes names, variables names and web controls IDs etc).

    MySQL, on the other hand, strictly sets the table names to be lower cases. This, however, doesn’t hurt much as we can manually change them before we generate the Business Objects. The rest, ie. the column names, are fine and work like a charm. If you’re deploying your database server on a Linux machine, don’t forget to set the lower_case_table_names=1 in the my.cnf file under the [mysqld] section.

    We’re going to come up with a solution to this problem in the next release (Covalentia Version 2.3 Reloaded).

So, stay tuned ;)

No comments: