Thanks again for your answers. Although this seems like an elegant solution, I would still want to know is what is the reason for this limitation:
"If someone can be both a Doctor and a Patient at the same time, I don't think 2 classes inheriting from User can really work any more" - Why? Amit On Tuesday, December 1, 2015 at 5:26:28 PM UTC+2, Simon King wrote: > > If someone can be both a Doctor and a Patient at the same time, I don't > think 2 classes inheriting from User can really work any more. Off the top > of my head, I might start with something like this (completely untested, > and the names are horrible, but hopefully you get the idea) > > class User(Base): > __tablename__ = 'user' > id = sa.Column(...) > email = sa.Column(...) > > patientdata = saorm.relationship("Patient", back_populates="user") > doctordata = saorm.relationship("Doctor", back_populates="user") > > @property > def is_patient(self): > return (self.patientdata is not None) > > @property > def is_doctor(self): > return (self.doctordata is not None) > > class Patient(Base): > __tablename__ = 'patient' > id = sa.Column(sa.ForeignKey(User.id), primary_key=True) > user = saorm.relationship(User, back_populates="patientdata") > > class Doctor(Base): > __tablename__ = 'doctor' > id = sa.Column(sa.ForeignKey(User.id), primary_key=True) > user = saorm.relationship(User, back_populates="doctordata") > > > You'd need to make some changes to the way you work with these objects > though. For example, when creating a new Patient, you'd need to explicitly > create the associated User object as well. > > Hope that helps, > > Simon > > On Tue, Dec 1, 2015 at 10:34 AM, amit geron <amit....@gmail.com > <javascript:>> wrote: > >> Hi Simon, >> >> Thanks for the reply. >> >> I will try to better explain what I was trying to do: >> >> - Created a general class User, which has a index (id) and unique >> attribute (email). >> - Created 2 sub-classes of User: Patient and Doctor, with primary >> foreign key User.id. >> - Basic assumption was that a patient is never a Dr. and vise-versa, >> hence if a user has registered as a Patient, he can never register as a >> Dr. >> (and vise-versa). >> - The latter assumption was broken with a new requirement, that a >> user may register with the same email both as a Dr. and a Patient. >> - As the tables were defined, it was possible (via MySQL commands) to >> add entries for an existing user in the opposite table, simply by >> specifying the user id upon insertion. >> >> So, the question is how can I do the last step using SQLAlchemy supported >> methods. If this is a design issue, please explain and advise what should >> be changed in order to support this structure. >> >> P.S. I changed the approach to solve this issue, but still want to gain >> better understanding of how to design and implement relationships). I've >> decided to completely separate the classes and remove the User class. >> >> On Tuesday, December 1, 2015 at 11:45:15 AM UTC+2, Simon King wrote: >>> >>> I don't understand exactly what you are trying to do here, from a >>> database perspective. Your table setup suggests that you are using >>> joined-table inheritance: >>> >>> >>> http://docs.sqlalchemy.org/en/rel_1_0/orm/inheritance.html#joined-table-inheritance >>> >>> ie. attributes that are common to all classes in the hierarchy live in >>> the base table, and attributes that are specific to one of the subclasses >>> live in a subclass-specific table. So when you have a user of type A, with >>> id 1, the common attributes will be in the user table with id 1, and the >>> A-specific attributes will be in the A table, again with id 1. >>> >>> If that's really what you've got, then it doesn't make any sense to >>> create a B object with an id of 1, since half of its identity would be the >>> same row as your A instance. I don't think SQLAlchemy will allow that. >>> >>> There are other inheritance patterns that might make sense for your >>> situation, or if you are trying to share state between and A and a B >>> instance then you probably don't want inheritance at all, but a shared >>> relationship instead. If you can tell us what you are trying to do, we >>> might be able to suggest an approach. >>> >>> Simon >>> >>> On Mon, Nov 30, 2015 at 4:46 PM, amit geron <amit....@gmail.com> wrote: >>> >>>> As I already mentioned, I tried your suggestion but with no success. >>>> The names are unique anyway, and I don't understand the how it's related >>>> to >>>> my question.. >>>> >>>> Could you please provide a working example that will demonstrate how 2 >>>> objects inherit from the same class, and hold the same primary key that is >>>> a primary foreign key of the derived class? >>>> >>>> >>>> On Monday, November 30, 2015 at 5:59:38 PM UTC+2, Jonathan Vanasco >>>> wrote: >>>>> >>>>> It should still work as a reference because the pacakge you use >>>>> doesn't override this. >>>>> >>>>> The extension's API makes this clear: >>>>> http://flask-sqlalchemy.pocoo.org/2.1/api/#models >>>>> >>>>> >>>>> _tablename__ >>>>> <http://flask-sqlalchemy.pocoo.org/2.1/api/#flask.ext.sqlalchemy.Model.__tablename__> >>>>> >>>>> The name of the table in the database. This is required by SQLAlchemy; >>>>> however, Flask-SQLAlchemy will set it automatically if a model has a >>>>> primary key defined. If the __table__ or __tablename__ is set >>>>> explicitly, that will be used instead. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "sqlalchemy" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to sqlalchemy+...@googlegroups.com. >>>> To post to this group, send email to sqlal...@googlegroups.com. >>>> Visit this group at http://groups.google.com/group/sqlalchemy. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sqlalchemy+...@googlegroups.com <javascript:>. >> To post to this group, send email to sqlal...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/sqlalchemy. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.