We're looking at doing something similar in our application. For all the attributes (even including the names of classes), we are looking to have API names and a field names. The API name will need to follow a given structure and can follow the field name. For instance, if the field name is "Switch is off", then the API name will be "switch_is_off" (snake_case) or maybe "switchIsOff" (camelCase). For custom attributes, we will be appending a "__c" at the end to differentiate them from system attributes. So the field "Switch is off" will be "switchIsOff__c". Still readable and usable for the developer.
Since field names are always language specific (and we are definitely shooting for a multilingual system), we are considering just holding the field names in a class made for translations. When the application is started, all the translations are loaded into a cache and used when needed. In other words, although the short name is a cool feature, it really doesn't help with a multilingual application, when it comes to having different class names. Now to my question. Instead of having a separate class for the field name translations, would it be possible to store the translations in the custom property metadata? Something like: orientdb> CREATE CLASS fooBar__c orientdb> ALTER CLASS fooBar__c CUSTOM fooBar__c_en = 'Foo Bar' Actually, I know the above would work, but is there a limit on the amount of properties that can be stored as custom property metadata? And, can the metadata be queried for and returned with the regular data in a select statement? If yes, what would such a query look like? Scott -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
