Model inheritance in different modules

[LBris]

Hi everyone,

Would it be possible to provide a new inheritance mechanism between classes in Django ?

I explain my point :

I have an app, for instance "HR": In this app, I would manage a model that is called "Employee". I store several information on this model and it's fine.

Suppose I have a SECOND app, for instance "Fleet". In this app, I would manage a model that is called "Vehicle" and of course I store several information on this model.

Suppose I only use the app "HR"  and one day, I decide to use the app "Fleet". That's okey, no problem. Both will work.

But what if I decide to create a THIRD app, for instance "HR-Fleet" that does the bridge between the two others ?

That means that HR can be used ALONE and same for Fleet.

But HR-Fleet would add additional information. For instance, on the employee we would add a field "company_car" that points to a vehicle. The trick is, it would be GREAT to be able to do that without creating additional table in the database.

Here is a sample of code to illustrate the behavior I'm trying to explain :

In app "HR" :

hr/employee.py :

class Employee(models.model):

   name = ...

   email = ...

In app "Fleet" :

fleet/vehicle.py

class Vehicle(models.model):

   brand = ...

   model = ...

   fuel_type = ...

In app "HR-Fleet" :

hr_fleet/employee.py :

class HRFleetEmployee(models.model):

   _inherit = <path_to_employee_model>

   company_car = models.ForeignKey(...)


And that would add an extra field on the Employee model without adding any table in the database or using proxy model or ...

Can you guys tell me if that behavior is possible ?

If you don't get the point of such a functionnality, I can try to give more details or be more clear.

Thanks in advance.

[Joe Tennies]

I think this is more of a django-users comment, so I'll post Adam's template for places.

I think you've found the wrong mailing list for this post. This mailing list is for the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely to answer your support query with their limited time and energy. Read more on the mailing lists at https://www.djangoproject.com/community/

For support, please use the NEW Django forum at https://forum.djangoproject.com , django-users mailing list, or IRC #django on Freenode, or a site like Stack Overflow. There are people out there willing to help on those channels, but they might not respond if you don't ask your question well. Stack Overflow's question guide can help you frame it well: https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of Conduct: https://www.djangoproject.com/conduct/ . These are our "ground rules" for working well as a community, and will help you get the most out of Django and our fantastic community.

Thanks for your understanding,

Adam

I'll send you a direct message.

Joe

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7800872b-6191-4505-b3bb-f726b0b92db3%40googlegroups.com.

--

Joe Tennies
ten...@gmail.com

[LBris]

No this is not a django-user-code related post. The code I provided was only an example to illustrate the feature request.

[Abhijeet Viswa]

How would the fields in HRFleetEmployee be persistent and linked to a particular Employee or Vehicle without being saved in the database? Or did I understand your code and request wrong?

[LBris]

I've never said it isn't saved in database. It is saved but in the table of the employee since hrfleetemployee inherits from employee. It simply adds this field to the table of Employee

Le jeu. 30 janv. 2020 à 5:24 PM, Abhijeet Viswa <abhije...@gmail.com> a écrit :

How would the fields in HRFleetEmployee be persistent and linked to a particular Employee or Vehicle without being saved in the database? Or did I understand your code and request wrong?

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAP1-YrrSo06-gxD1ZdzN0CCPQCm-shdah24H_ZVyLh_rGkU4%3DA%40mail.gmail.com.

[Abhijeet Viswa]

I think this would needlessly complicate the entire migration process. Two different app migrations (and possibly even more) would have be considered and executed in sequence to prevent anything breaking on the database.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJi3W9g2qa%2Bd1cXJNO2NJWfDpFTUHrqX2e%2B%2BS71KH2Wv9BeUuw%40mail.gmail.com.

--

Abhijeet

[LBris]

I do not understand. Could you explain to me what it would break the database and how ?

Le jeudi 30 janvier 2020 17:37:22 UTC+1, Abhijeet Viswa a écrit :

I think this would needlessly complicate the entire migration process. Two different app migrations (and possibly even more) would have be considered and executed in sequence to prevent anything breaking on the database.

On Thu, 30 Jan 2020 at 22:00, LBris <laurent...@gmail.com> wrote:

I've never said it isn't saved in database. It is saved but in the table of the employee since hrfleetemployee inherits from employee. It simply adds this field to the table of Employee

Le jeu. 30 janv. 2020 à 5:24 PM, Abhijeet Viswa <abhije...@gmail.com> a écrit :

How would the fields in HRFleetEmployee be persistent and linked to a particular Employee or Vehicle without being saved in the database? Or did I understand your code and request wrong?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAP1-YrrSo06-gxD1ZdzN0CCPQCm-shdah24H_ZVyLh_rGkU4%3DA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJi3W9g2qa%2Bd1cXJNO2NJWfDpFTUHrqX2e%2B%2BS71KH2Wv9BeUuw%40mail.gmail.com.

--

Abhijeet

[Abhijeet Viswa]

Each model represents one table on the DB. Modifying it in two different apps (hence creating two different sets of migrations) might result in breaking changes. What if one migration affects something that is directly referenced by the other app, but wasn't updated?

Also, what would the potential benefits be (other than reduction of number of tables) to such a type of inheritance? Couldn't the same be done with another table and a select related? The only difference would be a in prefetch_related call (your inheritance wouldn't require one). However, doing something that like that means the Employee app knows about (and relies upon) this backward relation to the Vehicle model (and hence the 2nd app itself).

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f58e79a0-6494-4a0a-ace8-e2cc31c799da%40googlegroups.com.

--

Abhijeet

[Steven Mapes]

It sounds to me like your data modelling is wrong. You can either have a one-to-one table2 acts as an extension of table1, a view that combines multiple tables into one "virtual table" or have one table and two models that use the table. One, the superset, would be managed, the other would only show a subset of the columns

Otherwise you risk adding fields into the subset model and assuming that they will be in the superset model which they won't unless you are inheriting from it and then overloading the meta.

On Thursday, 30 January 2020 16:30:36 UTC, LBris wrote:

I've never said it isn't saved in database. It is saved but in the table of the employee since hrfleetemployee inherits from employee. It simply adds this field to the table of Employee

Le jeu. 30 janv. 2020 à 5:24 PM, Abhijeet Viswa <abhije...@gmail.com> a écrit :

How would the fields in HRFleetEmployee be persistent and linked to a particular Employee or Vehicle without being saved in the database? Or did I understand your code and request wrong?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.

[LBris]

The thing is in my app, everything would be done on runtime. The idea is to have a minimal app "base" and once you're on in, you'd have a list of applications that you can install. So If I have "base" and "Employee", and then I want to install "Fleet", only migrations from Fleet would have to be done. The thing is it would be possible to install more apps only 1 by 1 ..

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f58e79a0-6494-4a0a-ace8-e2cc31c799da%40googlegroups.com.

--

Abhijeet