The standard to do that is by making it '0' which even MySQL accepts. with quotes, the standard is to use FALSE. I would like to have the columns as BOOLEAN instead of int because that's what it actually is supposed to be and we should leave it upto the database server to store however it wants to.
More can be seen here: http://www.postgresql.org/docs/9.0/static/datatype-boolean.html --- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 29 August 2011 11:48, Ben Wolfe <[email protected]> wrote: > The changes should be down at the db layer, right? I think that should be > fine. > > Is there a way to tell postgres to treat 0 like a 'false'? Perhaps with a > db connection string property? > > Ben > > > On Sun, Aug 28, 2011 at 5:42 AM, Saptarshi Purkayastha > <[email protected]>wrote: > >> One of the big problems that I'm encountering at the moment for making >> OpenMRS run on most database servers is with our assumption of the BOOLEAN >> type. Because MySQL stores BOOLEAN as TINYINT(1), we have made the >> assumption that BOOLEAN will be represented as 0 or 1. Thus, the column type >> for (retired, voided etc) in liquibase was using smallint (to make it >> ANSI-SQL :D) as the type and default as 0 (FALSE). This was fairly easy to >> change in the liquibase xmls by a search-and-replace (but still looking up >> all the columns) >> >> The bigger issue surrounding this assumption is in code, where we have >> made voided=0 in queries or getInt() from ResultSet. These are fine for the >> MySQL assumption, but doesn't work with other databases. This is a fairly >> big change to do, with changes at many places in code... >> >> Are we ready?? >> >> --- >> Regards, >> Saptarshi PURKAYASTHA >> >> My Tech Blog: http://sunnytalkstech.blogspot.com >> You Live by CHOICE, Not by CHANCE >> >> >> On 18 August 2011 15:59, Ben Wolfe <[email protected]> wrote: >> >>> 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 >>>> >>> >>> >> ------------------------------ >> 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]
