Sometimes, Servoy is not respecting upper and lower case. This has led to some problems: One example:
I have a table attribute named nameToCompareLength (which then is converted by Servoy to nametocomparelength. Then I created a calculation named nameToCompareLength, thinking that would lead to a stored calculation, because the rule for a stored calculation attribute is having the table attribute and calculation the same name. After a while I found that when I name the calculation nametocomparelength instead of nameToCompareLength it works. I don’t think is sensible if Servoy is going to change names or is there a reason for that?
maarten:
When you create a column in servoy it will always be corrected to lower case.
This is done because not all databases support “camel casing”
if you want a calculation to be a stored one, make sure the db column has exact name as the calculation.
Thanks for your reply! I think it’s quite annoying that Servoy corrects all attributes to lower case and makes the code much less readable, because one has first to figure out what the name means if it’s all lower case. I don’t know how other developers see it. But however, I think this could be easily solved if it is a Servoy preference one can choose (checkbox set) if necessary or leave if not necessary. Wouldn’t that be much more elegant? What do you think? I would like to make it a feature request.
Best regards, Robert
PS: By the way, can the iAnywhere db handle upper/lower case attributes or is it one of your mentioned databases which can not handle that?
general naming convention for db columns is my_database_column instead of myDatabaseColumn.
We haven’t had any complaints about this naming convention since Servoy went live.
If I were you I would stick to a naming convention that allows you to migrate to an other database whenever you want to.
Imagine a potential customer being interested in your solution but already has a working db, and doesn’t want to migrate to another DB platform.
Or a DB vendor that comes up with much better pricing model then the one you’re using. etc…
We’re always willing to take on feature requests , but if not many developers ask for it, there’s little chance it will make it into a build.
I agree with you, as I used to work with Oracle the way you mention. But with the introduction of OO, more and more developers use the upper/lower case writing, also of database attributes, it’s just more elegant and consistent with the variable etc. naming scheme. If I am the only one wishing this I am not asking for this preference setting (and going back to use the old naming convention), but I thought many other developers use it as well, as databases these days support it.
Best regards, Robert
maarten:
general naming convention for db columns is my_database_column instead of myDatabaseColumn.
We haven’t had any complaints about this naming convention since Servoy went live.
If I were you I would stick to a naming convention that allows you to migrate to an other database whenever you want to.
Imagine a potential customer being interested in your solution but already has a working db, and doesn’t want to migrate to another DB platform.
Or a DB vendor that comes up with much better pricing model then the one you’re using. etc…
We’re always willing to take on feature requests , but if not many developers ask for it, there’s little chance it will make it into a build.