dm-sql-finders 0.0.2 → 0.0.3

data/README.md

@@ -67,7 +67,8 @@ The DataMapper guys are hard at work creating DataMapper 2.0, which involves a l
 notably building DM's query interface atop [Veritas](https://github.com/dkubb/veritas), with the adapter layer generating
 SQL by walking a Veritas relation (an AST - abstract syntax tree).  Because of the way DM 1 handles queries, it is not
 trivial to support SQL provided by the user (except for the trival case of it being in the WHERE clause).  With any hope,
-gems like this will either not be needed in DM 2.0, or at least will be easy to implement cleanly.
+gems like this will either not be needed in DM 2.0, or at least will be easy to implement cleanly, since SQL and Veritas
+play nicely with each other.
 
 ## Installation
 
@@ -75,10 +76,6 @@ Via rubygems:
 
     gem install dm-sql-finders
 
-Note that while the gem is functional, it has several known limitations, which I aim to work about by improving the
-parsing and generating logic.  It is unlikely you will hit the limitations unless you extensively use `#by_sql` in
-conjunction with options such as `:links`.
-
 ## Detailed Usage
 
 Note that in the following examples, you are not forced to use the table representations yielded into the block, but you
@@ -90,7 +87,7 @@ are encouraged to.  They respond to the following methods:
   - `tbl.property_name`: represents the field name in the database mapping to `property_name` in your model.
 
 Writing the field/table names directly, while it will work, is not advised, since it will significantly hamper any future
-efforts to chain onto the query (and it reads just like SQL, right?).
+efforts to chain onto the query (and it reads just like SQL anyway, right?).
 
 ### Basic SELECT statements
 
@@ -112,6 +109,34 @@ def self.created_after(time)
 end
 ```
 
+### Selecting less than all fields
+
+Just specify individual fields in the SQL.  The regular DM semantics apply (i.e. the rest will be lazy loaded, and omitting the
+primary key means your records are immutable).
+
+``` ruby
+def self.usernames_only
+  by_sql { |u| "SELECT #{u.username} FROM #{u}" }
+end
+```
+
+### Selecting *more* than all fields (experimental)
+
+This allows you to pre-load things like aggregate calculations you may otherwise add denormalizations for:
+
+``` ruby
+def self.with_post_counts
+  by_sql(Post) { |u, p| "SELECT #{u.*}, COUNT(#{p.id}) AS post_count FROM #{u} INNER JOIN #{p} ON #{p.user_id} = #{u.id} GROUP BY #{u.id}" }
+end
+```
+
+A `@post_count` instnace variable is set on all resources.  Currently this is always a String.  You will need to typecast manually.
+
+See the section on "Joins" for details on the join syntax.
+
+You should consider this feature experimental.  It takes advantage of the fact DM Property instances can be created and thrown-away
+on-the-fly.
+
 ### Ordering
 
 DataMapper always adds an ORDER BY to your queries if you don't specify one.  DataMapper SQL Finders behaves no differently.
@@ -201,27 +226,33 @@ I have no idea what will happen if it is attempted, but it almost certainly will
 
 ## Will it interfere with DataMapper?
 
-Almost all of the implementation is unintrusive, but unfortunately, because DataMapper's DataObjects Adapter does not provide
-a great deal of flexibility when it comes to SQL generation, the entire `#select_statement` method has been overridden.  For
-non-`#by_sql` queries everything follows the original code pathways, and during a `#by_sql` query, the SQL is re-built using
-a combination of the original logic and some custom logic to include your SQL.  In short, yes, it does interfere, but I don't
-believe there are any alternatives without extensive work on DataMapper's Query interface and the DataObjects adapter itself.
+`#select_statement` on the adapter is overridden such that, when you use `#by_sql` query, code in the gem is executed, and
+when you execute a regular query, the original code pathways are followed.  I'd prefer some sort of extension API in
+DataObjectsAdapter to allow hooks into its SQL generation logic, but for now, this is how it works.
 
 DataMapper 2.0 *should* fix this.
 
 ## Contributors
 
-DataMapper SQL Finders is currently written by Chris Corbyn, but I'm extremely open to contributors which can make the
-extension feel as natural and robust as possible.  It should be developed such that other DataMapper gems (such as
-dm-aggregates and dm-pager) still function without caring that raw SQL is being used in the queries.
+DataMapper SQL Finders is currently written by [Chris Corbyn](https://github.com/d11wtq)
+
+Contributions are more than gladly accepted.  The primary goal is to support SQL in a way that does not break gems like dm-aggregates
+and dm-pager.  The more the SQL can be interpreted and turned into a native Query, the better.
 
 ## TODO
 
-  - Support overriding `:fields` in a `#by_sql` query (complex if the query depends on RDBMS native functions)
+There are some known limitations, that are mostly edge-cases.  You will only run into them if you try to get too crazy combining regular
+DM queries with SQL (e.g. adding `:links` to a hand-written SQL query works, unless you have used bind values somewhere other than the
+WHERE clause *and if*, and *only if* DataMapper needs to use a bind value in the join, such as for special join conditions).  Real
+edge-cases.
+
+  - Support overriding `:fields` in a `#by_sql` query (complex if the query depends on RDBMS native functions in both the WHERE and the SELECT)
   - Reverse the order when invoking `#reverse` in a `#by_sql` query that used `ORDER BY` in the SQL (note this will work just fine if
     you use the `:order` option)
   - Better support for `?` replacements in places other than the `WHERE` clause
   - Support set operations (union, intersection, difference)
+  - Possibly (?) support crazy complex mass-updates (seems a little DB-specific though):
+    `User.by_sql { ... something with join conditions ... }.update!(:banned => true)` (MySQL, for one, can do `UPDATE ... INNER JOIN ...`)
 
 ## Future Plans
 
@@ -233,7 +264,7 @@ therefore allowing you to simplify the query and let DMQL hande things like JOIN
 Post.by_dmql("JOIN User u WHERE u.username = ?", "Bob")
 ```
 
-Which would INNER JOIN posts with users and map u.username with the real field name of the `User#username` property.
+Which would INNER JOIN posts with users and map `u.username` with the real field name of the `User#username` property.
 
 This gem would be a pre-requisite for that.
 

data/lib/data_mapper/sql_finders/query.rb

@@ -35,6 +35,10 @@ module DataMapper
         def initialize(delegate)
           @delegate = delegate
         end
+
+        def dup
+          self.class.new(@delegate.dup)
+        end
       end
     end
   end

data/lib/data_mapper/sql_finders/version.rb

@@ -1,5 +1,5 @@
 module DataMapper
   module SQLFinders
-    VERSION = "0.0.2"
+    VERSION = "0.0.3"
   end
 end

data/spec/public/adapter_spec.rb

@@ -319,5 +319,13 @@ describe DataMapper::Adapters::DataObjectsAdapter do
         @users.to_a.first.post_count.should == 1
       end
     end
+
+    # fixed an obscure bug with state leakage here
+    describe "#reverse!" do
+      it "is consistent between invocations" do
+        User.all.query.reverse.order.first.operator.should == :desc
+        User.all.query.reverse.order.first.operator.should == :desc
+      end
+    end
   end
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: dm-sql-finders
 version: !ruby/object:Gem::Version
-  version: 0.0.2
+  version: 0.0.3
   prerelease: 
 platform: ruby
 authors:
@@ -9,11 +9,11 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2011-10-17 00:00:00.000000000Z
+date: 2011-10-20 00:00:00.000000000Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: dm-core
-  requirement: &13789500 !ruby/object:Gem::Requirement
+  requirement: &17003200 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -21,10 +21,10 @@ dependencies:
         version: 1.2.0
   type: :runtime
   prerelease: false
-  version_requirements: *13789500
+  version_requirements: *17003200
 - !ruby/object:Gem::Dependency
   name: dm-do-adapter
-  requirement: &13785560 !ruby/object:Gem::Requirement
+  requirement: &17002320 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -32,10 +32,10 @@ dependencies:
         version: 1.2.0
   type: :runtime
   prerelease: false
-  version_requirements: *13785560
+  version_requirements: *17002320
 - !ruby/object:Gem::Dependency
   name: rspec
-  requirement: &13783660 !ruby/object:Gem::Requirement
+  requirement: &17001160 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ~>
@@ -43,10 +43,10 @@ dependencies:
         version: '2.6'
   type: :development
   prerelease: false
-  version_requirements: *13783660
+  version_requirements: *17001160
 - !ruby/object:Gem::Dependency
   name: dm-migrations
-  requirement: &13782460 !ruby/object:Gem::Requirement
+  requirement: &16999680 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -54,10 +54,10 @@ dependencies:
         version: 1.2.0
   type: :development
   prerelease: false
-  version_requirements: *13782460
+  version_requirements: *16999680
 - !ruby/object:Gem::Dependency
   name: dm-aggregates
-  requirement: &13779440 !ruby/object:Gem::Requirement
+  requirement: &16995420 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -65,10 +65,10 @@ dependencies:
         version: 1.2.0
   type: :development
   prerelease: false
-  version_requirements: *13779440
+  version_requirements: *16995420
 - !ruby/object:Gem::Dependency
   name: dm-sqlite-adapter
-  requirement: &13778640 !ruby/object:Gem::Requirement
+  requirement: &16993080 !ruby/object:Gem::Requirement
     none: false
     requirements:
     - - ! '>='
@@ -76,7 +76,7 @@ dependencies:
         version: 1.2.0
   type: :development
   prerelease: false
-  version_requirements: *13778640
+  version_requirements: *16993080
 description: ! "dm-sql-finders add #by_sql to your DataMapper models and provides
   a clean mechanism for using\n                     the names of the properties in
   your model, instead of the actual fields in the database. Any SQL\n                     is