The funny thing is that the liquibase changeset files were used for the initial scripts was for database portability. If you can export them as standard sql files and run those just as easily as the liquibase ones, go for it. The tricky thing to solve would be how to get the progress bars to work in the initialization wizard.
You can either change the datatypes to a generic ansi standard ones, or change to something that liquibase knows about and converts to each different datatype on the different dbms's correctly. Ben On Wed, Aug 17, 2011 at 10:47 PM, Saptarshi Purkayastha <[email protected]>wrote: > 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 >> >> >> > ------------------------------ > 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]
