patient.patient_id and person.person_id *must* continue to match for now. There is code in both openmrs and in modules that makes that assumption. Until we scour the code looking for and fixing these, this needs to remain.
The constraint means that when the person.person_id column is changed, the patient.patient_id column updates automatically. We've never actually used this. And I'm not sure other rows like patient_identifier.patient_id are also "update on change". The reason this has worked for us is because the person row is created first, then the patient row. The patient.patient_id will be inserted as whatever value is in the person.person_id column. The patient.patient_id should not be an auto increment. You are allowed to specify a value for an auto increment row on insert, it will simply update the next increment value for you to what-you-put-in + 1 (at least mysql does). There might be a changeset later that removes patient.patient_id autoincrement...I think that was screwing up the guys using the datamodel with ruby. Ben On Tue, Aug 30, 2011 at 6:04 AM, Burke Mamlin <[email protected]>wrote: > There should be a later changeset that removes the constraint. > > -Burke > > > On Mon, Aug 29, 2011 at 10:03 PM, Saptarshi Purkayastha > <[email protected]>wrote: > >> Hi Burke, >> >> I wasn't thinking of users.user_id though... >> From what I understand is that when creating a patient, we want the >> underlying person to be created and hence that constraint from the >> changeset, but how do we ensure that the person_id won't collide with an >> existing person_id that was auto-generated for person table?? >> >> Or am I not understanding that constraint correctly?? >> Or did u mean that constraint is not required anymore and we can remove >> that changeset?? >> >> --- >> Regards, >> Saptarshi PURKAYASTHA >> >> My Tech Blog: http://sunnytalkstech.blogspot.com >> You Live by CHOICE, Not by CHANCE >> >> >> On 30 August 2011 07:24, Burke Mamlin <[email protected]> wrote: >> >>> 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 >>> >>> >>> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > 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]
