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 > _________________________________________ 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]
