When the person table was first introduced as a shared foundation for all people in the system (we started with just patient & users), we made the mistake of forcing the same ID across them (patient_id == person_id == user_id). We since relaxed that, introducing patient.person_id and users.person_id, so patient_id & user_id are no longer guaranteed/required to be the same as the matching person_id.
Lesson learned. -Burke On Mon, Aug 29, 2011 at 9:31 PM, Saptarshi Purkayastha <[email protected]>wrote: > I was looking through the liquibase-schema-only.xml which creates the base > schema for OpenMRS. > > Changeset 1227303685425-232 generates the following constraint: > ALTER TABLE patient ADD CONSTRAINT person_id_for_patient FOREIGN KEY > patient_id REFERENCES person.person_id ON UPDATE CASCADE > > I was left thinking how this has been working till now... patient_id is > auto-increment and person_id is also auto-increment and both are primary > keys of their respective tables viz. patient and person. Since we have an > UPDATE CASCADE, a new patient_id will be sent as person_id... but how is > that they will be able to generate the auto-incremented ids correctly?? > > How is it that primary key IDENTITY column is a FOREIGN KEY to another > table's IDENTITY PRIMARY KEY column?? I'm confused how this works?? and > isn't it logically incorrect?? > > --- > Regards, > Saptarshi PURKAYASTHA > > My Tech Blog: http://sunnytalkstech.blogspot.com > You Live by CHOICE, Not by CHANCE > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
