database-agnostic

I have these two lines in my model, written for PostgreSQL: named_scope :by_month, lambda { |month| { :conditions => ["EXTRACT(MONTH FROM recorded_on) = ?", month] }} named_scope :by_year, lambda { |year| { :conditions => ["EXTRACT(YEAR FROM recorded_on) = ?", year] }} I'm running PostgreSQL in production, but I'm developing with SQLite3. How can I write those lines in a way that is database-agnostic? Btw, "recorded_on" is formed from the following: Model.recorded_on = Time.parse("Fri, 01 May 2009 08:42:23 -0400") Okay, found out there's a better way (thanks to this article ): Basically do

While looking for java libraries to build queries in a database agnostic way I came across many including iciql, querydsl, jooq, joist, hibernate etc. I wanted something that does not require configuration files and can work with dynamic schemas. For my application, I come to know about the database and the schema at runtime so I won't have any configuration files or domain classes for the schema. This seems to be one of the core goals of querydsl but going through the documentation for querydsl I see a lot of examples for building dynamic queries using domain classes but I have not come

I'm currently using Oracle, but most of the SQL is db agnostic. One exception is CURRENT_TIMESTAMP which fails in MSSQL. Is is possible to move to a more portable syntax for this too? According to their documentation the following vendors support CURRENT_TIMESTAMP . Oracle Postgresql MySQL SQL Server Firebird H2 HSQLDB DB2 Vertica InterSystems Caché Doctrine Teradata In summary, CURRENT_TIMESTAMP is the method stated in the SQL Standard, a summary of which is below, and if you are looking for DB agnostic SQL the best you can really do is stick to the standard, although this does not guarantee

Does "group by" clause automatically guarantee that the results will be ordered by that key? In other words, is it enough to write: select * from table group by a, b, c or does one have to write select * from table group by a, b, c order by a, b, c I know e.g. in MySQL I don't have to, but I would like to know if I can rely on it accross the SQL implementations. Is it guaranteed? juergen d group by does not order the data neccessarily. A DB is designed to grab the data as fast as possible and only sort if necessary. So add the order by if you need a guaranteed order. An efficient

I realize this question is very likely to have been asked before, but I've searched around a little among questions on StackOverflow, and I didn't really find an answer to mine, so here goes. If you find a duplicate, please link to it. For some reason I prefer to use Guid s ( uniqueidentifier in MsSql) for my primary key fields, but I really don't know why this would be better. In many of tutorials I've walked myself through lately an automatically incremented int has been used. I can see pro's and cons with both: A Guid is always of the same size and length, and there is no reason to worry