From: Jess Robinson Date: Mon, 12 Mar 2012 12:50:11 +0000 (+0000) Subject: Cleanup and remove non-working parts and comments X-Git-Tag: v1.0~2^2 X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=7d48ee14e8f230430919ebbf89375a4897a99cfe;p=dbsrgits%2FDBIx-Class-Manual-SQLHackers.git Cleanup and remove non-working parts and comments --- diff --git a/lib/DBIx/Class/Manual/SQLHackers/CREATE.pod b/lib/DBIx/Class/Manual/SQLHackers/CREATE.pod index 7601a74..6319275 100644 --- a/lib/DBIx/Class/Manual/SQLHackers/CREATE.pod +++ b/lib/DBIx/Class/Manual/SQLHackers/CREATE.pod @@ -53,8 +53,6 @@ Run the included L script. =head2 Manual Result class creation (and understanding Loader results) -# note - CREATE INDEX is a bitch these days (requires a deploy hook) - perhaps not mentioning it at all is wise-ish? -# Leaving in as it is possible, and anyway the only index I mentioned so far below was a unique one (really should add the deploy hook stuff, this is about describing the possible, not the simple) This section covers the common and oft used CREATE DDL statements that DBIx::Class can replaces with Perl classes: B, B and B. The classes can be used to write the actual SQL DDL to the database or disc, if required. =head3 CREATE TABLE @@ -233,7 +231,20 @@ To add extra unique indexes, add the B call to your Resul __PACKAGE__->add_unique_constraint('username_idx' => ['username']); -## Should add how to create a non-unique index via deploy hook here. +=head4 NON-UNIQUE indexes + + CREATE INDEX user_email_idx ON user (username, email); + +These are not created or used by DBIx::Class itself, but can be added so that deploying (creating DDL SQL from your Schema) can include them. + +The B method allows you to add L code to your Result class. It is called with the SQL::Translator::Schema::Table object, and allows you to amend the Table before it is converted into SQL. + + sub sqlt_deploy_hook { + my ($self, $sqlt_table) = @_; + + $sqlt_table->add_index(name => 'user_email_idx', fields => ['username', 'email']); + } + =head3 Outputting SQL DDL @@ -257,10 +268,6 @@ Create a schema object with the a database connection (any will do), and call th If called with no arguments, this method will create an SQL file each for MySQL, PostgreSQL and SQLite. More databases are supported by L if necessary. -### IIRC this is not true - one can not do diffs without Schema::Versioned -### which is not loaded by default (and will soon be deprecated anyway, given how far frew and jnap have gone) -## No thats rubbish, my usual use-case is to not use versioned at all, but have create_ddl_dir output me the diff files, thats where they come from. (unless someone has stuffed that up and I havent noticed..) - =head4 SQL files for upgrades (ALTER TABLE) DBIC can also make use of L to write out ALTER TABLE statements when the schema classes are changed. diff --git a/lib/DBIx/Class/Manual/SQLHackers/UPDATE.pod b/lib/DBIx/Class/Manual/SQLHackers/UPDATE.pod index 9debfb4..1620acd 100644 --- a/lib/DBIx/Class/Manual/SQLHackers/UPDATE.pod +++ b/lib/DBIx/Class/Manual/SQLHackers/UPDATE.pod @@ -139,75 +139,6 @@ To update a whole set of rows, or all of them, we first need to create a ResultS =back -=head2 Update a row or rows using a column calculation - - -- Yet another pointless example - UPDATE users - SET username = username || '.uk' - WHERE id = 1; - -=over - -=item 1. Create a Schema object representing the database you are working with: - - my $schema = MyDatabase::Schema->connect('dbi:SQLite:my.db'); - -=item 2. Call the B method on the resultset for the L you wish to fetch data from: - - my $fred_user = $schema->resultset('User')->find({ id => 1 }); - -The Row object has an B method that will change the values on -the object, and send an UPDATE query to the database. - -=item 3. Call the B method, passing it a hashref of new data: - -# this won't yet work, DBIC for now mandates the [ {} => $value ] format, the simple \[ $sql, $value1, $value2 ] will start being recognized later on -# the only documentation we currently have is this, if you can turn it into a DBIC pod-patch it will be freaking awesome -# https://github.com/dbsrgits/dbix-class/commit/0e773352 - $fred_user->update({ username => \['username || ?', '.uk'] }); - -^^ you never got around to this - -# the DBIC syntax is a tad different from te thing above (i.e. we no longer encourage 'dummy' crap) -The \[ .. ] syntax here is described in L -documentation, used for passing bind parameters. - - -=back - -=head2 Update a row based on data in other tables - - -- Slightly less pointless example - UPDATE posts - SET title = user.username || title - JOIN users user ON user.id = posts.user_id; - -Joining two tables for an update is a similar sort of exercise to -joining them for a select query and using data from both. - -=over - -=item 1. Create a Schema object representing the database you are working with: - - my $schema = MyDatabase::Schema->connect('dbi:SQLite:my.db'); - -=item 2. Call the B method on the resultset for the L you wish to update data in, joining to the second table: - - my $posts = $schema->resultset('Post')->search( - {}, - { join => 'user' } - ); - - The B key takes as an argument a nested structure of one or more relation names (see L). - -=item 3. Call the B method on the resultset to run the UPDATE statement: - - $posts->update({ 'me.title' => \[ 'user.username || me.title' ] }); - -^^ I am 95% sure this won't actually work, please try it (ideally as a passing or failing test) - -=back - =head2 Update or create a row -- MySQL non-standardness (and another silly example) @@ -237,9 +168,6 @@ To avoid race conditions, this should be done in a transaction. my $schema = MyDatabase::Schema->connect('dbi:SQLite:my.db'); =item 2. Call the B method on the schema object, passing it a coderef to execute inside the transaction: -^^ ouch! I didn't realize we don't do that automatically, this is a bug -^^ probably a good idea not to mention it - I'll fix it @ GPW -## Not entirely sure what thing you mean here.. $schema->txn_do( sub {