Hi. I'm wondering if this concept is good enough to warrant inclusion in core:
SQL-statements / conditions mostly consists of these things: Fields - Datamapper::Property (check) Operators - DataMapper::Query::Operator (check) Functions - ? I'm not talking about aggregate-functions (although they better inherit from a function-object instead of using a hack-like Operator like in dm- aggregates). All the major databases have support for a wide-range of functions, especially handy date-time functions. I haven't quite settled on syntax yet, but would it not be cool if you could easily do stuff like this in dm (I dont want to extend symbol with even more methods): (A gist with the code here: https://gist.github.com/1e2cdf0b320efab93840) Call.all(:created_at.fn(:day) => 1..5) # Select calls from work-days Call.all(:created_at.fn(:day) => 6) # Only saturday Call.all(:created_at.fn(:quarter) => 4) # All calls in winter-quarters Order.all(:confirmed_at.fn(:strftime, '%Y-%W') => '2007-41') # week 41 in 2007 Errors.all(:at.fn(:hour) => 18..24) # Errors happening after regular work-hours User.all(:name.fn(:length).gte => 10) # User with name Not all of these are good / plausible examples, but I hope you get the idea. DM could easily implement a good set of consistent functions across all of the rdb-adapters. When/if Ambition is implemented in dm this would (kick ass)^2 Call.all{|c| c.created_at.day == 6 } # Select calls from sunday Call.all{|c| c.created_at.year == 2007 } # Select calls from 2007 User.all{|u| u.name.length >= 10 } # Users with a username longer than 10 We could easily implement lots of 'native' ruby as high-perf sql- statements that works just as if working with an enumerable. This takes ambition even one step further (imo). Now that JRuby has a parse-tree going for it, I think we can begin to play with the thought of implementing ambition :-) ------------------------------------------------------------------------------- The reason I post this on the mailing-list is this: I'd have no problem with implementing it as a plugin, but it is certainly not possible without some ugly hacks and alias-method-chain. And since it is an integrated part of most rdbs I think it could fit into core alongside Properties and Operators. We wouldnt even need to implement any specific functions in core, just allow for it, and plugins can add functions later. This will also make dm-aggregates a whole lot cleaner and 'better' if it can extend Function and create real aggregate-functions without resorting to rewriting chunks from data-objects-adapter etc. So, is it possible this could get into core? If there is a small chance, I will fork dm-core, implement it, and then let sam decide wether it could be merged back in. But I really think it should be considered, as functions are a large part of moderately complex and optimized queries. If I make it easy to extend to, we can add lots of cool extra postgres- stuff in a plugin at a later point (postgres has extremely many handy functions). It will not mess up much / any code in data-objects, just need to see if a object is a function, and then delegate to a method like 'function_statement' a few different places. (Also need to add something along those lines in Query) I'm also thinking about the possibility to add functions / dynamic properties to resource, so you can do: class User ... property :created_at, DateTime property :answered_at, DateTime property :terminated_at, DateTime function :weekday, Function(:day, :created_at) # or: function :weekday, DayFunction(:created_at) end So you can use it just like a normal property in queries. Call.all(:weekday => 1..5) @user.calls(:order => [:weekday.asc]) etc ... This would obviously be a plugin though :-) Best regards Sindre (somebee) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
