Hello all,
In TDM v2 I’m attempting to create a variable that works like %relname%. What I mean is that I am trying to create a variable that can be used in other fields within the UI.
I’ve defined the variable in the Editor Of Variables and that part is straight forward. However if you type special characters like % into the UI they are transcoded to underscores in some cases and in others not treated like a variable. Is there any way to ensure that a variable can travel from the UI to the generation process intact and decoded?
Thank you,
Kelley Eitzen
California Public Utilities Commission
Hi Kelley,
your question is related to TDM version 2, not TDM 3 BETA. I just want to make it clear to other readers of your post.
To your question: in TDM 2 there are several internal macros available:
Relations:%parenttablename%
%childtablename%
%relname%
%parententityname%
%childentityname%
Model properties:
%entname%
%atrname%
%dictname%
Patterns:
%tmplNow% - time stamp
%tmplDate% - date
%tmplTime% - time
%tmplTriggerName% - trigger name
%tmplTableName% - table name (for triggers only)
%tmplProcedureName% - stored procedure name
%tmplViewName% - view name
All those macros were created by TDM2 makers and users cannot easily enlarge the list of available internal macros. In general, the Editor of variables cannot be used for that purpose. Please have a look at the following movie to find out how to use Editor of variables:
http://www.casestudio.com/enu/learning_center.aspx?fromUrl=tdm_010_templates_editor.swf
I believe the use of your macros could be replaced by some small template which will replace existing values across your model with required, most up-to-date values. But
I think I need more information from you. Where do you wish to use your macro and for what purpose? Let me know what you need to do and I’ll try to create an example for you.
Regards,
Vaclav
Thank you Vaclav, at least now I know there’s no easy way to duplicate default functionality. So I’ll just have to determine the best way to accomplish what I need.
The reasoning for this is that we have requirements on the format of constraint names. All constraints have the format: type_tableAbbreviation_column (where type is 3 characters or less and table abbreviation is 5 characters or less). Since the same table abbreviations are used for PK, FK, UK, NN, CK it means typing essentially the same thing many many times.
My intention was to create a variable, say %tableabbr%, so that I could automatically populate constraint names with ex. pk_%tableabbr%_%atrname%. For each table you could go to the advanced tab and create your abbreviation once and all constraints would be named automatically upon generation. If you ever changed the abbreviation all the constraints would be updated automatically as well.
I know that I could create a template which would perform a renaming pass upon demand. This would reduce developer time but would need to be run after any changes. We do have multiple developers though and I always prefer to limit manual processes and human error as much as possible.
My current thinking is that I could create a jscript function which accepts a constraint name and a user variable name, returning the altered constraint name. It could replace occurances of the user variable with the table abbreviation to simulate default functionality. This would require extensive editing of the existing templates to ensure all occurances of the constraint name were replaced with the function but it would only have to be done once.
Hi Kelley,
thanks for the clarification. I’ve prepared a sample template for you (attached, feel free to import it into TDM2 via Template Editor) and tried to describe what can and cannot be done in TDM2. All important information are in the attached *.pdf file.
In general, you can call your templates whenever you execute the SQL script generation, for example. There is no need to force users to do additional actions…
The example just renames existing PK and check constraint names, but I guess it will be easy for you to write a script that will take existing value, combine it with your variable values and replace the original value with the newly created one.
Regards,
Vaclav
renamecheckconstraint.pdf (462 KB)
Hi Kelley,
thanks for the clarification. I’ve prepared a sample template for you (attached, feel free to import it into TDM2 via Template Editor) and tried to describe what can and cannot be done in TDM2. All important information are in the attached *.pdf file.
In general, you can call your templates whenever you execute the SQL script generation, for example. There is no need to force users to do additional actions…
The example just renames existing PK and check constraint names, but I guess it will be easy for you to write a script that will take existing value, combine it with your variable values and replace the original value with the newly created one.
Regards,
Vaclav
renamecheckconstraintskelley.zip (2.22 KB)
Thank you for working that up. It’s always helpful to see someone else’s solution to a problem. I decided to go ahead and create my own macros as you mentioned. The modification of the system templates doesn’t really bother me and I think it’s the most versatile solution I can implement. I actually based mine off of the ModifyFkIndexName script since you guys had already done essentially the exact same thing.
I’ve created my %tableabbr% macro and it works like a charm. The NN, CK, UN constraints are all pretty easy to fully automate. I’m working on a few snags & I’ll let you know how it goes.
Thanks again,
Kelley
Ok, I did get everything working correctly now. It all works like default functionality now so it will be much easier for our devs to create standardized keys. I found that I had to pass PkChildName and ConstraintPkName to my jscripts because there doesn’t seem to be a corresponding interfaces from iRelation and iEntity. It’s not a big deal but I found it strange. I would offer you a package of what I came up with but I’ve made other unrelated changes to the system templates to fit our format.
I did find a minor bug in the process of doing all of this. I’m not sure if maybe it is intended to work this way but it was a head scratcher for a few minutes. Apparently PkChildName doesn’t get a current value until you run ForRelPk(). It doesn’t have to be nested or have any parameters, it just has to be called before you can reliably use PkChildName. If you don’t call ForRelPk the value in PkChildName will either be null (the first time) or it will contain the value from the last Relation in the ForChild() iteration.
By the way, how much of the generation script is planned to be changed by the release of version 3? I don’t mind implementing these changes for the new version but I’d like to get an idea of whether it will be necessary. I could base this answer on the beta version but I thought you might have some further insight if there are any upcomming changes.
Thank you,
Kelley
Hello Kelley,
thanks for your feedback and please accept my apologies for so late reply. I was out of my office for several days.
I am glad you got familiar with the internal scripting so quickly and that everything you needed works. Also, thank you for reporting us the bug. Honestly, I don’t think we will release a patch for this because TDM3 now has a higher priority. Thank you for understanding it.
TDM3 scripting will be different. Much more flexible and comfortable. Users will not have to modify system templates, they will be allowed to extend them. JScript and internal scripting languages will be used in system templates. We will prepare a documentation to the scripting, but it will take some time. I really believe that modifying/extending scripts in TDM3 will be worth any end-user’s time.
Regards,
Vaclav