How to save an inline model in the admin panel if the id of the parent model is not yet saved in the database?

Question

Django

Good day, community!
Intro: I am new to Linux and Python. I am currently practicing writing in Django. Decided to move away from blogging and write "local air bnb". The bottom line is simple: the admin starts a new apartment, with a description, coordinates and photos of the interior. The interior is "connected" as inline in the apartment (many-to-one). Also in the interior there is a photo of the interior, with the same many-to-one relationship. If you first save flat, then create and save the interior, and only then upload
and save the photo, then everything is fine
photo (in mycase based on the id of the apartment and interior, which are not yet recorded in the database), then the path will be formed in the form of FlatNone/InteriorNone/...
Options found in the open spaces:
1) set file names differently and do not arrange them in folders. The perfectionist in me resists this decision.
2) Use presave. Namely, until the moment of "standard" saving, save the id of the apartment, and then the id of the interior. But it turns out that at the moment of "standard" saving there will be one more call to the database. The same perfectionist strikes. Here it is interesting to hear the opinion of the community, maybe I'm overcomplicating.
3) Another option is possible: rewrite the save method so that the flat model is saved first, then the interior, and then the photo. But at this thought, my knees begin to tremble and I want to look at someone's example and hear advice. Most hardly it will turn out to make normal redefinition.
Yes, and I'm sorry that the code in the turnip doesn't look very good, sometimes I can't resist and I'm commencing it as it is, because it "worked!" ;)
Sincerely.

Answer 1

Faced once with the same problem. But out of laziness, I decided to follow the Sorl Thumbnail principle, which forms paths like this:
In other words, each picture receives a random UUID as a name and is decomposed into folders from its first characters. We get a uniform layout across folders, which eliminates the worry about the possible slowdown of the file system with a large number of files in a folder. We get rid of the need to normalize file names (and if there are Cyrillic characters in the name? will all system components react favorably to this?). Instead, we lose the correspondence between the structure of the file system and the structure of Django models. PMSM, it's irrelevant; maybe your situation is different and this method will not work.

Answer 2

If you want to pamper a perfectionist, then definitely the third option. In practice, everyone uses the option described by Altaisoft and does not worry.

Answer 3

Thanks for the replies and advice.
2 Altaisoft:
Yes, I tried to do something similar. UID was the result of a hash function from time to time + something else. And I normalized the names, no Cyrillic and spaces. But this is not convenient for
1) debugging - to see what the photo handler did or where the JS goes for the photo.
2) for hypothetical support and scalability. A friend who develops iOS in moments of dispute teaches me what to think about their followers - they can rummage through sftp, look at the code of the page, do anything else and be very surprised. In addition, it’s somehow not beautiful that the framework can generate urls to pages in a human-readable format, but the developer blundered on media files.
3) for admins/managers of the site, such a hierarchy will also move your hair in one place. But it’s easier with them if you try hard and finish the admin panel. With what I'm still not okay)
2 nekt:
I really want to. but scary. I don't even know how to get on. Do you happen to have your own implementation of such things? Think carefully before answering, because then I will not be left behind with questions)
On the weekend I will google again and if someone writes here about the possibility of helping, I propose to parse some "just working example". It's just that the same questions were not raised on stackoverflow.