Plugin Development Foreingkey namespace.

[renatoalmeidaoliveira]

When developing a plugin it's possible to create Foreingkey to base models, like Device, Tenant....
With the possibility for the community create puglins it's might ocour attribute name collisions, so there're any recommendation about "namespacing" the attributes?
Something like always use your related name prepending your plugin name.

[jeremystretch]

When defining a ForeignKey, you can specify its to attribute using a string concatenating the model's app and name. For example:

site = models.ForeignKey(
    to='dcim.Site',
    on_delete=models.CASCADE
)

Aside from that, you just need to be careful when importing classes from other apps. (You can often work around conflicts by doing e.g. import foo as bar.) Is there a specific problem you're running into?

[renatoalmeidaoliveira]

It's not about the 'to' attribute.
Imagine that one developer creates a ForeignKey to the Device model and uses the related_name='documents' like that.

device = models.ForeignKey(
        to='dcim.Device',
        on_delete=models.CASCADE,
        related_name='documents'
    )

Then other developer in other plugin uses the same related_name, then when the final user loads both plugins, we have a problem in the database migration, because the model uses the same attribute for multiple foreign tables.

[jeremystretch]

Unfortunately I don't think there's much we can do about that. You could prefix the related name with the name of your plugin to avoid the likelihood of a collision, but I'd recommend forgoing the related name entirely (since it exists only for convenience). You can do this by setting related_name='+', which instructs Django not to add the related name on the referenced model.

[renatoalmeidaoliveira]

I know, I bring this topic because as the plugin developer community grows, we problably gonna face issues related with names collisions, so it would be great to have some development standarts, like: "Netbox core team reccomends to avoid using related_name, ie using related_name='+', but if your plugin requires related name for side_plugins for example, always prepend your plugin name to the attribute".
That way I think that collisions problems might be reduced.

[hagbarddenstore]

There’s another problem and that is the inevitable merge conflicts with migrations. If you use related_name=‘+’ you avoid that issue.

…

Sent from my iPhone

On 25 Apr 2022, at 16:40, Renato Almeida de Oliveira ***@***.***> wrote:  I know, I bring this topic because as the plugin developer community grows, we problably gonna face issues related with names collisions, so it would be great to have some development standarts, like: "Netbox core team reccomends to avoid using related_name, ie using related_name='+', but if your plugin requires related name for side_plugins for example, always prepend your plugin name to the attribute". That way I think that collisions problems might be reduced. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[candlerb]

Why is that? I thought a related_name on the target model would only affect the python model, and not touch the database structure?