Why Names of Relations has to be Unique

Hi to All,

I’m trying our structure with the new features of v17 - especially ORDA. And I’ve discovered (and realized) a thing that makes me think. Let’s assume there is a table with customers and there are 2+ tables relating to those customers eg address and eMailAddress.

In my world of thinking: I would name the relations (and especially there to-one direction) belongsTo or belongsToCustomer. In order to write code like

$eMail.belongsToCustomer.LastName

and somewhere other

$Address.belongsToCustomer.Lastname

But this is not possible. In the current implementation of ORDA and 4D, I need to “write” code like

$eMail.eMailAddressBelongsToCustomer.LastName

$Address.Address.BelongsToCustomer.LastName

In my opinion, this makes the code less easy to read and makes it - perhaps in some situations - necessary, to make relation names that are not very fluently or “natural”. I understand, that relation names need to be unique in the context of a table but not in the context of a structure with 200+ tables.

Is this “subject-to-be-changed” or will this be a very long lasting behavior of ORDA/4D that is (nearly) unchangeable?

Have a nice weekend

Christian

: Christian MITTERMAIR

Is this “subject-to-be-changed” or will this be a very long lasting
behavior of ORDA/4D that is (nearly) unchangeable?

Export your structure as XML (feature available since v11).

Start reading from top. You will see all tables, all fields.
After scrolling through your 200+ tables, you will find a block of relations.

Each relation has an UUID and two names:
uuid=“9C94C42CE5C6E44CA22D5020DFC0EF0E” name_Nto1=“customer” name_1toN=“invoices”

each of this 3 attributes are unique, as they are used to identify the relation.
Inside the relation you’ll find the identification of used fields/tables.

As you can see, the structure is based on unique names.

Of course another structure/total redesign is possible, but it would break compatibility with existing applications (which is not far away from unchangeable).

On the other side, that’s a name. And names might have an alias. And that alias could define more than just a name. Visitors of last 4D Summit(s) and LR’s master class might remember him mentioning some ideas for the future, how to add such features to the structure. Kind of virtual layer on top. This could answer your need, maybe better, maybe not.

Till then, yes, you need to spend some time to think about good, useful, understandable and fluent names. The first names will be difficult. Customer_Invoice is a bad example for such a name, even it would be unique.
It may be more difficult in some languages/countries as in others.
Best practice is to use Singular for Ntow1 and Plural for 1toN. Again, in some countries easy, in some difficult.
Invoice_Address looks strange, while (German) Rechnungsanschrift is the usual and fluent way to name that, so just use it for the relation name. There are of course examples where English is more easy.

: Christian MITTERMAIR

In order to write code like

$eMail.belongsToCustomer.LastName

and somewhere other

$Address.belongsToCustomer.Lastname

But this is not possible.

I do this every day and it works. The relation-name itself must not be unique:

[]26337615;“Your comment here…”[/]

true.

Don’t know why, but I was sure it needed to be unique.
Just tried, not needed anymore.

Honestly, I run into that when we introduced 4D Mobile (which is using internally the same REST communication between Wakanda and 4D Server which is now used for ORDA between 4D Client and Server), changed my naming and never checked again.

With v17 I just renamed some relations to already existing work. It is an old (back to v1) structure, so it is not related to creation date of the structure.

Mr Mittermair, if this don’t work in your structure, please open a tech support case.

You will start laughing - I know this feature. and as I remember this structure file was crucial when importing/opening old (pre v11) datafiles with structures from v11 ongoing. And as there IS a UUID I really cannot understand why the names also need to be unique. Especially from the standpoint of table design/normal forms - “WHY” someone needs an artificial PK IF other attributes are already unique.

I totally understand, that this is a NECESSARY feature for older versions. AND i totally understand, that all structures converted to v17 has this cryptic and never used before relation names. And as no one (in practical situations) is using 4D relation names so this design does not hurt anybody.

BUT

as there is no possibility to go back from v17 to EVEN v16 R3, why is it necessary to keep this restriction. Only for those guys who export the structure from v17 start-up v11, import there the XML definition and import data will ever have a problem, if there is a “not-unique” relation name.

Prior to v11 everything had a number (i mean table and field numbers). But since v11 every ERM “thing” has a UUID for identifying the table, attribute, relation, constraint and so on and so forth. This restriction of naming relations uniquely in 4D could also be expanded to name fields uniquely in the whole database so that only one attribute could have the name UID. Your “solution” of making aliases could work there also and it is theoretical a thinkable solution to put an alias on top of it. But you will also say that this is to speak in german - das Pferd von hinten aufzäumen. I even cannot think of a situation where 4D internal needs a unique contraint name AS there is a UUID.

In my expirience it’s much easier to soften hard restrictions than to harden loose restrictions. As there is a UUID for identifing what is the special need for sticking to also unique names.

I suppose aliases will ease it but every alias makes a structure just more complex and will stay there forever and always as no one will track each change and deletes not used aliases unless there is a tool for finding them.

I cannot reproduce thise behavior you describe.

[]26338362;“4D v16.4”[/]

The icon is purple, not green, so you are using v16, not v17.
ORDA was introduced with v17. Could you please try again with v17?

And as I wrote, I think it was unique some time before and confirmed that it is not unique anymore with v17.

Sorry for the missleading icon. I’ve tried it in v17 and afterwards in v16 to check if this is because of my v17 version… the upload was the false screenshot.

I tried to narrow down my problem. I’ve restarted the server with the structure and from now on it works. But I have plenty of other tables and relations to reproduce the behavior. Perhaps this is because of too many changes without restart?!

Have a nice weekend

Christian