Gmail Calendar Documents Reader Web more »
Recently Visited Groups | Help | Sign in
Google Groups Home
Message from discussion General development question about other dependencies other than JAVA
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Logan Barnett  
View profile  
 More options Jan 16, 11:24 am
From: Logan Barnett <logus...@gmail.com>
Date: Fri, 16 Jan 2009 09:24:16 -0700
Local: Fri, Jan 16 2009 11:24 am
Subject: Re: General development question about other dependencies other than JAVA
Greg,
Here's the adapter (and a mixin) yanked out of our project:

h2_date_fix.rb
require 'time'

module H2DateFormat
   def h2_format
     self.strftime("%Y-%m-%d %H:%M:%S")
   end
end

class Date
   include H2DateFormat
end

class DateTime
   include H2DateFormat
end

h2.rb (lives in sequel_core/adapters/jdbc
module Sequel
   module JDBC
     # We override the default behavior to ensure that column names  
are returned as lower-case strings
     class Dataset

       # alias_method :original_execute_dui, :execute_dui

       def quoted_identifier(name)
         name.to_s
       end

       def fetch_rows(sql, &block)
         execute(sql) do |result|
           # get column names
           meta = result.getMetaData
           column_count = meta.getColumnCount
           @columns = []
           # downcase added by JGB
           column_count.times {|i| @columns << meta.getColumnName(i
+1).downcase.to_sym}

           # get rows
           while result.next
             row = {}
             @columns.each_with_index {|v, i| row[v] =  
result.getObject(i+1)}
             yield row
           end
         end
         self
       end

       # For whatever reasons, the default insert was not passing  
along the :type value, so later code
       # did not know to go grab the last_insert_id
       def insert(*values)
         execute_dui(insert_sql(*values), {:type => :insert})
       end

     end
   end

   class Database
     def serial_primary_key_options
       {:primary_key => true, :type => :identity, :auto_increment =>  
false}
     end

     def last_insert_id(conn, opts={})
       stmt = conn.createStatement
       begin
         rs = stmt.executeQuery('SELECT IDENTITY(); ')
         rs.next
         rs.getInt(1)
       ensure
         stmt.close
       end
     end
   end

end

module Sequel
   module JDBC
     module H2
       module DatabaseMethods
         def last_insert_id(conn, opts={})
           stmt = conn.createStatement
           begin
             rs = stmt.executeQuery('SELECT IDENTITY(); ')
             rs.next
             rs.getInt(1)
           ensure
             stmt.close
           end
         end
       end
     end
   end
end

I'm not sure if this is all you need (does this get required  
somewhere?). James may need to chime in on that part.

On Jan 16, 2009, at 7:13 AM, GregD wrote:

> Hey James,

> I've been talking to Jeremy at the Sequel project.  He'd like you to
> submit the H2 adapter if it is usable even if it is not perfect, but I
> understand if you are wanting to clean it up before hand.  I'm giving
> this a try on my own if you can't get to it.  I want to get going on
> my project using H2 DB and also I need the experience because my work
> uses Sybase and I'll need to do the same for Sybase, if I want to
> steer them toward this technology.  My feelings are if I can get
> something working I might have a chance with that, otherwise, I'm
> fearing that they will continue to gravitate toward "Micro-suck"
> technologies like .NET, C#, SqlServer, etc.  I'm not a fan of those.
> Also, if I win this battle we can gravitate away from Sybase because
> of the ORM layer, but that will be a longer process because of all the
> stored procs they are using right now.  I'm not a fan of a lot of
> stored procs either.  They have their place, but using too many can
> get you stuck to a DB because of the porting issues of the code will
> take too many man-hours.

> Sorry for the rant.

> Later,

> GregD

> On Jan 12, 3:39 pm, James Britt <james.br...@gmail.com> wrote:
>> GregD wrote:
>>> Yes, it would be nice to have it submitted to the sequel project or
>>> available some way.

>> Sigh. :)

>> We'll get the code out one way or anther.  The plan is to clean it  
>> up,
>> make sure it passes some specs, and submit it to the Sequel project.

>> Absent that, if that drag on, maybe we could just post it someplace.

>> --
>> James Britt

>> www.happycamperstudios.com  - Wicked Cool  
>> Codingwww.jamesbritt.com          - Playing with Better  
>> Toyswww.ruby-doc.org            - Ruby Help &  
>> Documentationwww.rubystuff.com           - The Ruby Store for Ruby  
>> Stuff


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2009 Google