+1 to Nuwan's suggestion. I too have experienced inconsistencies in the past while using the -Dsetup when configuring the databases where we still have to manually execute the scripts. Since we are not using this feature in production environments I think it wouldn't hurt to get rid of this all together. Since we can always run the relevant scripts manually, if there is no significant advantage of keeping this feature I think it's a good idea to remove it. Just my personal opinion.
Cheers, Pubudu. Pubudu D.P Senior Software Engineer - QA Team | WSO2 inc. Mobile : +94775464547 Linkedin: https://uk.linkedin.com/in/pubududp Medium: https://medium.com/@pubududp On Wed, Jul 13, 2016 at 11:35 AM, Nuwan Dias <[email protected]> wrote: > Practically the -Dsetup option is never used in production. All "real" > users of our products have DB admins and all that who carefully evaluate > and execute our DB scripts on their Database servers. They would never > allow a product startup process to create tables and indexes at will on > their database servers. > > So I think we should just remove this option all together. I know we've > done that on C5 but it probably makes sense to remove this option in C4 > products as well. We sometimes even have to make design changes to our > features to support this option (when two features have their own DB > scripts). And I think its a complete waste because we're compromising the > design of our products to support a feature thats never used in the real > world. > > Thanks, > NuwanD. > > On Wed, Jul 13, 2016 at 11:05 AM, Pubudu Priyashan <[email protected]> > wrote: > >> >> Hi all, >> >> When we use MySql 5.7 as the DB and start the server with -Dsetup without >> manually executing the scripts at DB level, we have observed the issue >> logged at [1] while testing wso2esb-5.0.0-PRE-BETA2-PACK1.zip pack. The >> reason behind this is, by default the pack is picking up mysql.sql script >> located at [$HOME]/dbscripts directory when started with -Dsetup. A >> solution was suggested in this comment [2] to rename the mysql5.7.sql >> scripts as mysql.sql when using MySql 5.7 db and we have verified that this >> suggestion fixed the issue. We have logged a doc JIRA to include that >> information at [3] for now. >> >> Our concern is since this is going to affect all the products when using >> MySql5.7 do we have a better solution to automatically select the >> mysql version without having to rename the script? Is it possible to add a >> property to define the db version somewhere and then point to the relevant >> script without renaming the script when starting with -Dsetup? Or any >> better solution if possible. Appreciate your feedback on this. Thanks! >> >> >> [1] https://wso2.org/jira/browse/ESBJAVA-4748 >> [2] >> https://wso2.org/jira/browse/ESBJAVA-4748?focusedCommentId=123463&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-123463 >> [3] https://wso2.org/jira/browse/DOCUMENTATION-3604 >> >> >> Cheers, >> Pubudu D.P >> Senior Software Engineer - QA Team | WSO2 inc. >> Mobile : +94775464547 >> >> Linkedin: https://uk.linkedin.com/in/pubududp >> Medium: https://medium.com/@pubududp >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
