Yes, remove the autoincrement in both the schema-only.xml setup file and add a changeset to the liquibase-update-to-latest.xml file to change it.
Ben On Tue, Aug 30, 2011 at 12:25 PM, Saptarshi Purkayastha <[email protected]>wrote: > 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 >>> >> >> > ------------------------------ > 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]
