MySQL longtext is the same as the TEXT of postgresql... for the others we have to make database specific options between the data types tinyint to smallint in the liquibase-schema-only there are many similar difference that are database specific and we have to make database specific datatypes.
I'm yet to go through all the changes required... but will make as these come. But for datatypes that are incompatible, probably be database specific. Is that ok?? or we should move those to ANSI-standard ones only?? --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 18 August 2011 00:48, Darius Jazayeri <[email protected]> wrote: > Hi Saptarshi, > > In principle I'm fine with these, but let's get at the specifics of > datatypes. > > We probably use the mysql text, mediumtext, and longtext types a lot, > because they're really usefully-sized datatypes. What will we replace those > with? > > What other datatypes are you expecting to change? > > -Darius > > On Wed, Aug 17, 2011 at 11:25 AM, Saptarshi Purkayastha > <[email protected]>wrote: > >> Hi, >> >> While we were recently discussing that OpenMRS should run on multiple >> database servers, I started working on Support Multiple Databases in >> OpenMRS Installation and >> Update<https://tickets.openmrs.org/browse/TRUNK-1925> >> . >> There are some of the following broad changes that need to be made the the >> liquibase xml so that we can install OpenMRS on different databases (target >> MySQL, Postgres, MsSQL... and may be later Oracle). >> >> 1.) Change datatypes and create tables that are compatible with all the >> databases (directly for compatible types or database specific for >> non-compatible types) >> 2.) Remove precision from many columns which are not compatible across all >> those database servers >> 3.) Divide a larger changeset into smaller changeset so that they can be >> done commonly (by changing syntax) across multiple database servers. >> 4.) Due to move to liquibase 2.0, all checksums for changesets have been >> NULL'd and then changed to the new format. This should happen automatically, >> but if anyone depends on these checksums, then you should reply to this >> email :) >> >> We may also have to change if anywhere non-ANSI syntax or MySQL-syntax has >> been used in the DAO. I haven't reached that far to tell how many such >> instances exist, but I hope there aren't many such places >> >> What do other developers think about these changes? Any suggestions on the >> way?? Anything that u think should be avoided or done?? These are fairly >> large changes and may result in incompatible checksums for already run >> changesets. >> >> >> PS: On a sidenote, I would like to highlight that for new installations it >> is silly that we are doing changesets based installations. While the world >> has moved to image based deployments for OS and large-software packages, we >> did the reverse and moved to changesets based installations. Upgrades are >> easier through changesets, but for new installations they are lengthy and >> boring. I would like to propose the for new installations, just an sqldump >> deploy is easy and fast, while keeping to changesets for upgrades. >> >> --- >> 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]
