yes, so that was my understanding as well. We should remove the auto-increment on the patient.patient_id then... Because if the database engine is clever enough (... and more ACID than MySQL) it does not allow you to create that foreign key changeset that I talked about...
So, is it fine that I remove that auto-increment from the liquibase-schema-only.xml and add a changeset that deletes the auto-increment in liquibase-update-to-latest.xml. I couldn't find it in the current liquibase-update-to-latest.xml doing anything like this... --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 30 August 2011 11:59, Ben Wolfe <[email protected]> wrote: > > 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]
