Add docs on performance optimizations.

[Kircheneer]

Closes #98

[jdrew82]

LGTM!

[chadell]

I don't see any mention of the atomic transaction topic, and how to leverage post_run.
Also, I think it could be interesting to introduce the trade-off of using bulk operations

[Kircheneer]

I don't see any mention of the atomic transaction topic, and how to leverage post_run. Also, I think it could be interesting to introduce the trade-off of using bulk operations

I wanted to (for now) stick to things for which I concretely know that they don't pose any negatives, with post_run losing the atomic transaction and resulting in abnormal job behavior (you have to manually reload the job result, it shows as completed too early) and bulk operations not running custom model validation or even save methods.

These optimizations could be documented at a later point in time IMO.

[chadell]

Add .idea to gitignore

[chadell]

Yes, they can be added in another PR, but they are in the scope of #98 issue

[Kircheneer]

I have responded to most the requests now. Open points:

Using bulk_create

I don't feel good recommending this in the documentation as is right now because of its severe trade-offs:

• No change log
• No model validation (depending on this model this ranges from okay to very bad - take a look at the Cable model for example: https://github.com/nautobot/nautobot/blob/develop/nautobot/dcim/models/cables.py#L149 - leaving it up to the user to re-implement these validations feels like a very bad idea and could lead to their instance being rendered unusable)
• No custom save methods (again, this depends on the model - its really bad for device https://github.com/nautobot/nautobot/blob/develop/nautobot/dcim/models/devices.py#L814 - not using this custom save method would lead to no device components being created

I argue that we need explicit Nautobot core support for this to be reasonable.

Parallelizing the load functions

I think this needs to be supported from SSoT itself rather than a recommendation in the docs for people to build it themselves. To me it only spells trouble when users would have to convert their custom methods of parallelization to a method that eventually will be supported out of this app.

@chadell thoughts?

[chadell]

on't feel good recommending this in the documentation as is right now because of its severe trade-offs:

• No change log
• No model validation (depending on this model this ranges from okay to very bad - take a look at the Cable model for example: https://github.com/nautobot/nautobot/blob/develop/nautobot/dcim/models/cables.py#L149 - leaving it up to the user to re-implement these validations feels like a very bad idea and could lead to their instance being rendered unusable)
• No custom save methods (again, this depends on the model - its really bad for device https://github.com/nautobot/nautobot/blob/develop/nautobot/dcim/models/devices.py#L814 - not using this custom save method would lead to no device components being created

I argue that we need explicit Nautobot core support for this to be reasonable.

1. If we do not document it (even for discouraging), someone else will ask the question again. I prefer to be explicit about it, so everyone can make their own decisions. I mean, documenting != recommending.
2. Parallelization of load jobs should be out of the scope, as it will be tackled after Nautobot 2.0 release. The other question is parallelizing a single job with concurrent API operations. Again, I am not saying we recommend doing it, but explaining potential pros/cons will make everyone understand it.

[Kircheneer]

All feedback addressed

[chadell]

LGTM