LOAD DATA INFILE 'D:\\sql_data\\available_samples.csv' INTO TABLE sample FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (id, version, barcode, used) SET last_updated = NOW(), date_created = NOW();
alexgorbatchev
Friday, August 30, 2013
Using MySQL LOAD DATA INFILE on Windows
Many times I need to load data into the MySQL database backing my Grails application before my initial release. And frequently those databases include tables with last_updated and date_created timestamp fields. Instead of entering the values into a csv file, I found it is very easy to set them programmatically while loading other data from a file like the following:
Wednesday, August 28, 2013
My Grails Workflow: New Project Setup
Configuration changes
Build Config Changes- add organization's artifact repository to buildConfig.groovy
mavenRepo https://my.url.org/nexus mavenRepo https://my.url.org/artifactory
- Update all the plugins in buildConfig.groovy. Some of these plugins mature faster than the Grails releases and need to be updated when starting a new project.
- Add (uncomment) cached resources - creates a hash of resources and sets expire headers so that your resources will not be downloaded over and over, helping to speed up your application
- Add (uncomment) zipped resources - gzips the static resources in your application
- Add build-test-data plugin - provides data that meets your domain constraints so you can concentrate on data under test
- Add fixtures plugin - allows you to define dummy data for tests and development in the form of spring beans
- Add spock plugin, if necessary - BDD Testing framework that makes tests much more expressive
dependencies { test "org.spockframework:spock-grails-support:0.7-groovy-2.0" //Required for Grails v2.2+ } plugins { runtime ":hibernate:$grailsVersion" runtime ":jquery:1.8.3" runtime ":resources:1.1.6" runtime ":zipped-resources:1.0" runtime ":cached-resources:1.0" runtime ":database-migration:1.3.2" build ":tomcat:$grailsVersion" compile ":cache-headers:1.1.5" compile ":cache:1.0.1" compile ":build-test-data:2.0.5" test (":spock:0.7") { exclude "spock-grails-support" } test ':fixtures:1.2'
}
- Remove production block from datasource.groovy (leaving the development and testing blocks). I would remove all content, however, it appears that the database migration plugin has problems using alternative datasource configuration files when performing diffs/updates (http://jira.grails.org/browse/GPDATABASEMIGRATION-63)
- Add <my app>-config.groovy to root directory for externalized configuration
- Add /*-config.groovy to .gitignore to exclude it from the code repo.
This one is from Programming Grails by Burt Beckwith. Make target your work directory. This moves generated files, compiled classes, and installed plugins under the target directory and allows you to delete all of it by removing the target directory. This can help when Grails gets out of sync with your source code.
Change
grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
To
grails.project.work.dir = 'target'
Setup/Preparation for Future Work
Front-End Development PreparationCreate and configure.editorconfig (This is not playing well with Intellij)- Disable caching, zipping, etc in development mode. This will allow you to make edits to the css and javascript while debugging/testing
development { grails.resources.debug = true }
Get the resources and artifacts prepared for the future. I like to setup the changelog prior to creating any domain classes. This makes changelog.groovy a simple list of includes.
dbm-generate-changelog changelog.groovy
Subscribe to:
Posts (Atom)