Re: setting up the SQLite database
Thanks Nokan, Dave, Philippe for your replies, it's good to get a measure of standard practice even for things as simple as this. There just remains no. 4 (from a question by Isak Andersson http://comments.gmane.org/gmane.comp.lang.ruby.camping.general/1751) for which I'd like an opinion, since I can't find a definitive answer from the AR docs... and can only fond a reference to it on the Ember GitHub readme: https://github.com/EmberAds/acts_as_uuid or slide 21 of this AR intro: http://www.slideshare.net/blazingcloud/active-record-introduction-3 since I've only ever used 'up' and 'down' (and don't use Rails) this isn't obvious to me :-) Finally, what's a good approach to security (SQL injection?) for a public app? DaveE 4. There's also this from a previous post (opinions please?): On the part of migrations ... def self.up and def self.down ... gave me errors for some reason. But ... it should be updated to def self.change ... that's the modern way of doing it. DaveE ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: setting up the SQLite database
On 4: http://api.rubyonrails.org/classes/ActiveRecord/Migration.html#label-Reversible+Migrations Looks like you just define the up, AR takes care of the rest. Never tried it, it'll save a few lines of code though. On injection, AR sanitizes almost everything I believe. The only thing I know to avoid is using a user set variable straight in a string: thing = #{@input.user_var} That's dangerous, you're supposed to do this: thing = ?, @input.user_var Dave On Mon, May 21, 2012 at 4:52 AM, Dave Everitt dever...@innotts.co.uk wrote: Thanks Nokan, Dave, Philippe for your replies, it's good to get a measure of standard practice even for things as simple as this. There just remains no. 4 (from a question by Isak Andersson http://comments.gmane.org/gmane.comp.lang.ruby.camping.general/1751) for which I'd like an opinion, since I can't find a definitive answer from the AR docs... and can only fond a reference to it on the Ember GitHub readme: https://github.com/EmberAds/acts_as_uuid or slide 21 of this AR intro: http://www.slideshare.net/blazingcloud/active-record-introduction-3 since I've only ever used 'up' and 'down' (and don't use Rails) this isn't obvious to me :-) Finally, what's a good approach to security (SQL injection?) for a public app? DaveE 4. There's also this from a previous post (opinions please?): On the part of migrations ... def self.up and def self.down ... gave me errors for some reason. But ... it should be updated to def self.change ... that's the modern way of doing it. DaveE ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Dave ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: setting up the SQLite database
I personally always use a config/database.yml file as I like to keep the configuration out of the code. Plus it makes it easier to switch between development and production configuration. E.g. for Heroku: dbconfig = YAML.load(File.read('config/database.yml')) # On Heroku the production database,yml is configured automatically environment = ENV['DATABASE_URL'] ? 'production' : 'development' Camping::Models::Base.establish_connection dbconfig[environment] On 5/15/2012 11:39 AM, Dave Everitt wrote: I know this isn't Python, but I'd like to get a view on the 'one obvious' way to set up an SQLite (or other) database and its location per-app. I've got a bit lost with the Camping 2 changes and various code snippets I have kicking around. 1. is it best to set up the DB creation/connection: 1.1 at the end of the app AppName::Models::Base.establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/myApp.db' ) run AppName #from an old snippet 1.2 OR like this (postgres) example [Magnus]: def List.create List::Models::Base.establish_connection( :adapter = postgresql, :username = root, :password = toor, :database = list ) List::Models.create_schema end 1.3 in a config/database.yml file [Magnus] (probably not worth it for SQLite): --- adapter: postgresql username: root password: toor database: mycampingdb And then do: require 'yaml' def AppName.create AppName::Models::Base.establish_connection(YAML.load(File.read(database.yml))) AppName::Models.create_schema end 2. since sqlite is the default, is it necessary to set :adapter explicitly if that's what I'm using? def AppName.create AppName::Models::Base.establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/.camping.db' ) end 3. Since .create is *only needed once* to set up the database (Magnus: if you connect to a database which already has the tables, DON'T run `AppName::Models.create_schema` as this will probably delete the whole database.) what do we do with this after the first run: def AppName.create AppName::Models.create_schema end 3.1 delete it after the db is created on the first run? 3.2 check if the db already exists (best way, please)? 3.3 check like this (never understood ':assume'?): AppName::Models.create_schema :assume = (AppName::Models:: table_name.table_exists? ? 1.0 : 0.0) or could we do something simpler like (?): AppName::Models.create_schema unless table_exists?(table_name) ? 4. There's also this from a previous post (opinions please?): On the part of migrations ... def self.up and def self.down ... gave me errors for some reason. But ... it should be updated to def self.change ... that's the modern way of doing it. DaveE ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: setting up the SQLite database
Hi, Just a comment: I don't think it's a good practice to set the database details (establish_connection() call) in the application itself. It's an environmental issue, and this way you lose the possibility to move your app between dev, ((devtest)), (test) and production environments without modifications. On Tue, May 15, 2012 at 7:39 PM, Dave Everitt dever...@innotts.co.ukwrote: I know this isn't Python, but I'd like to get a view on the 'one obvious' way to set up an SQLite (or other) database and its location per-app. I've got a bit lost with the Camping 2 changes and various code snippets I have kicking around. 1. is it best to set up the DB creation/connection: 1.1 at the end of the app AppName::Models::Base.**establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/myApp.db' ) run AppName #from an old snippet 1.2 OR like this (postgres) example [Magnus]: def List.create List::Models::Base.establish_**connection( :adapter = postgresql, :username = root, :password = toor, :database = list ) List::Models.create_schema end 1.3 in a config/database.yml file [Magnus] (probably not worth it for SQLite): --- adapter: postgresql username: root password: toor database: mycampingdb And then do: require 'yaml' def AppName.create AppName::Models::Base.**establish_connection(YAML.** load(File.read(database.yml)**)) AppName::Models.create_schema end 2. since sqlite is the default, is it necessary to set :adapter explicitly if that's what I'm using? def AppName.create AppName::Models::Base.**establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/.camping.db' ) end 3. Since .create is *only needed once* to set up the database (Magnus: if you connect to a database which already has the tables, DON'T run `AppName::Models.create_**schema` as this will probably delete the whole database.) what do we do with this after the first run: def AppName.create AppName::Models.create_schema end 3.1 delete it after the db is created on the first run? 3.2 check if the db already exists (best way, please)? 3.3 check like this (never understood ':assume'?): AppName::Models.create_schema :assume = (AppName::Models:: table_name.table_exists? ? 1.0 : 0.0) or could we do something simpler like (?): AppName::Models.create_schema unless table_exists?(table_name) ? 4. There's also this from a previous post (opinions please?): On the part of migrations ... def self.up and def self.down ... gave me errors for some reason. But ... it should be updated to def self.change ... that's the modern way of doing it. DaveE __**_ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/**listinfo/camping-listhttp://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
setting up the SQLite database
I know this isn't Python, but I'd like to get a view on the 'one obvious' way to set up an SQLite (or other) database and its location per-app. I've got a bit lost with the Camping 2 changes and various code snippets I have kicking around. 1. is it best to set up the DB creation/connection: 1.1 at the end of the app AppName::Models::Base.establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/myApp.db' ) run AppName #from an old snippet 1.2 OR like this (postgres) example [Magnus]: def List.create List::Models::Base.establish_connection( :adapter = postgresql, :username = root, :password = toor, :database = list ) List::Models.create_schema end 1.3 in a config/database.yml file [Magnus] (probably not worth it for SQLite): --- adapter: postgresql username: root password: toor database: mycampingdb And then do: require 'yaml' def AppName.create AppName ::Models ::Base.establish_connection(YAML.load(File.read(database.yml))) AppName::Models.create_schema end 2. since sqlite is the default, is it necessary to set :adapter explicitly if that's what I'm using? def AppName.create AppName::Models::Base.establish_connection( :adapter = 'sqlite3', :database = '/path/to/my/app/.camping.db' ) end 3. Since .create is *only needed once* to set up the database (Magnus: if you connect to a database which already has the tables, DON'T run `AppName::Models.create_schema` as this will probably delete the whole database.) what do we do with this after the first run: def AppName.create AppName::Models.create_schema end 3.1 delete it after the db is created on the first run? 3.2 check if the db already exists (best way, please)? 3.3 check like this (never understood ':assume'?): AppName::Models.create_schema :assume = (AppName::Models:: table_name.table_exists? ? 1.0 : 0.0) or could we do something simpler like (?): AppName::Models.create_schema unless table_exists?(table_name) ? 4. There's also this from a previous post (opinions please?): On the part of migrations ... def self.up and def self.down ... gave me errors for some reason. But ... it should be updated to def self.change ... that's the modern way of doing it. DaveE ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list