General development question about other dependencies other than JAVA
GregD
So far I like the building of a cross-platform app with rawr using
monkeybars. Looks like monkeybars and rawr make this task seem less
because don't have to worry about ruby being installed and just the
version of java and launch4j helps with that. My question is: if my
app depends on something other than java to run like a cross-platform
database like MySql, Sqlite3, etc., what is the best way of insuring
that they are on the app's system? Do I just include them some way in
the packaging of the app? Or, do I write specialized java class to
handle dependency checking a launch time? I'd like to to the last
option without the writing of code and just configure the
dependencies. Any suggestions on an approach?
Logan Barnett
On Jan 9, 2009, at 8:55 AM, GregD wrote:
>
> Hey newbie here.
>
> So far I like the building of a cross-platform app with rawr using
> monkeybars. Looks like monkeybars and rawr make this task seem less
> because don't have to worry about ruby being installed and just the
> version of java and launch4j helps with that. My question is: if my
> app depends on something other than java to run like a cross-platform
> database like MySql, Sqlite3, etc., what is the best way of insuring
> that they are on the app's system?
installer. I'd recommend you go with one of the local file-based
databases if your app's DB isn't going to get super huge, and there's
no need to host/share the data.
In JRuby, I believe Sqlite support isn't 100%, but this has been a
changing thing. There's also Derby and H2. For our JotBot application,
we switched to H2 after using Derby for a little bit. Both Derby and
H2 are pure Java local file SQL databases, can be connected to with
JDBC, and require no native extensions. I believe Sqlite will require
native extensions.
> Do I just include them some way in
> the packaging of the app? Or, do I write specialized java class to
> handle dependency checking a launch time?
created if it doesn't exist when you go to connect to it. Packing the
database library is as simple as dropping in a jar. My impression is
that local databases don't get as much love as something like MySql in
terms of support, so you may have to write your own adapter to make it
work. I believe we had to write an adapter for JotBot to use H2 for
Sequel.
GregD
Okay, this makes sense. One more follow-up question on Derby or H2.
You said I'd have to write an adapter for them. I'm assuming that you
mean an activerecord adapter, correct? You can say duh, if that was
obvious.
Thanks,
GregD
GregD
Is ActiveRecord an option? I'm familiar to Rails development.
Thanks,
GregD
Logan Barnett
On Jan 9, 2009, at 9:24 AM, GregD wrote:
>
> Okay, I looked up Sequel...
>
> Is ActiveRecord an option? I'm familiar to Rails development.
>
filesystem, and this was causing problems for us with packaging. We
ultimately went with Sequel (which, while poorly named, is probably a
better ORM than ActiveRecord in terms of magic, capability, and lazy
execution). While ActiveRecord has a Derby adapter (I'm not sure about
H2), we had to write our own adapter for H2. I'm not sure if we
submitted it to the Sequel guys or not. However, I do recall that
there wasn't much to it.
James Britt
>
>
> ActiveRecord makes a lot of assumptions about being a gem on your
> filesystem, and this was causing problems for us with packaging. We
> ultimately went with Sequel (which, while poorly named, is probably a
> better ORM than ActiveRecord in terms of magic, capability, and lazy
> execution). While ActiveRecord has a Derby adapter (I'm not sure about
> H2), we had to write our own adapter for H2. I'm not sure if we
> submitted it to the Sequel guys or not. However, I do recall that
> there wasn't much to it.
No, submitting the adapter back to the Sequel project is still on my To
Do list.
But it was not a big deal; mostly copied from another adapter.
There is also, as I recall, a bug in Sequel regarding JDBC dates. It
was fixable by overwriting a particular method that handles format
conversion, which I think I added to our H2 adapter.
--
James Britt
www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation
www.rubystuff.com - The Ruby Store for Ruby Stuff
GregD
same gem assumption issues as ActiveRecord? Looking up Sequel and
ActiveRecord, I found DataMapper. What I have been reading is that AR
is not so good and that is all that I'm familiar with. Did you try
DataMapper as an ORM before going with Sequel for a standalone, non-
web, app? Or, is Sequel the best option?
Thanks for the heads up on AR being this is my first attempt at this
technology and being familiar with Rails with AR, I was going to try
AR. After reading articles and your input, I'll not be using AR and
you probably saved me a bunch of grieve.
GregD
Logan Barnett
On Jan 9, 2009, at 10:17 AM, GregD wrote:
>
> Awesome, guys. One more and hopefully last: Is DataMapper have the
> same gem assumption issues as ActiveRecord? Looking up Sequel and
> ActiveRecord, I found DataMapper. What I have been reading is that AR
> is not so good and that is all that I'm familiar with. Did you try
> DataMapper as an ORM before going with Sequel for a standalone, non-
> web, app? Or, is Sequel the best option?
project out there that's working to port that over to something we can
use in JRuby, but it's not ready for production apps yet. Had that not
been the case, we probably would have went with DataMapper instead.
GregD
Which adapter did you guys copy for H2? And how many changes were
involved? I started down this path.
Thanks,
GregD
>
> > ActiveRecord makes a lot of assumptions about being a gem on your
> > filesystem, and this was causing problems for us with packaging. We
> > ultimately went with Sequel (which, while poorly named, is probably a
> > better ORM than ActiveRecord in terms of magic, capability, and lazy
> > execution). While ActiveRecord has a Derby adapter (I'm not sure about
> > H2), we had to write our own adapter for H2. I'm not sure if we
> > submitted it to the Sequel guys or not. However, I do recall that
> > there wasn't much to it.
>
> No, submitting the adapter back to the Sequel project is still on my To
> Do list.
>
> But it was not a big deal; mostly copied from another adapter.
>
> There is also, as I recall, a bug in Sequel regarding JDBC dates. It
> was fixable by overwriting a particular method that handles format
> conversion, which I think I added to our H2 adapter.
>
> --
> James Britt
>
GregD
Which adapter did you guys copy for H2? And how many changes were
involved? I started down this path.
GregD
>
> > ActiveRecord makes a lot of assumptions about being a gem on your
> > filesystem, and this was causing problems for us with packaging. We
> > ultimately went with Sequel (which, while poorly named, is probably a
> > better ORM than ActiveRecord in terms of magic, capability, and lazy
> > execution). While ActiveRecord has a Derby adapter (I'm not sure about
> > H2), we had to write our own adapter for H2. I'm not sure if we
> > submitted it to the Sequel guys or not. However, I do recall that
> > there wasn't much to it.
>
> No, submitting the adapter back to the Sequel project is still on my To
> Do list.
>
> But it was not a big deal; mostly copied from another adapter.
>
> There is also, as I recall, a bug in Sequel regarding JDBC dates. It
> was fixable by overwriting a particular method that handles format
> conversion, which I think I added to our H2 adapter.
>
> --
> James Britt
>
Stephen Bannasch
>Logan Barnett wrote:
>>
>we had to write our own adapter for H2. I'm not sure if we
> > submitted it to the Sequel guys or not. However, I do recall that
>> there wasn't much to it.
>
>
>No, submitting the adapter back to the Sequel project is still on my To
>Do list.
I would love to see your H2 adapter for Sequel in the wild -- is it
in a public repository?
GregD
available some way.
GregD
On Jan 12, 12:05 pm, Stephen Bannasch <stephen.banna...@deanbrook.org>
wrote:
James Britt
> 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.
GregD
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
>
Logan Barnett
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.
James Britt
>
> I'm not sure if this is all you need (does this get required
> somewhere?). James may need to chime in on that part.
>
I changed typecast_value in jdbc/mysql.rb (which I believe other
adapters reuse) because it was incorrectly altering the format of
date/datetime values. The change is in the
when :datetime
clause.
Mind the FIXME comment
:)
#---------- BEGIN ------------
# Typecast the value to the given column_type. Can be overridden in
# adapters to support database specific column types.
# This method should raise Sequel::Error::InvalidValue if assigned value
# is invalid.
def typecast_value(column_type, value)
return nil if value.nil?
case column_type
when :integer
begin
Integer(value)
rescue ArgumentError => e
raise Sequel::Error::InvalidValue, e.message.inspect
end
when :string
value.to_s
when :float
begin
Float(value)
rescue ArgumentError => e
raise Sequel::Error::InvalidValue, e.message.inspect
end
when :decimal
case value
when BigDecimal
value
when String, Float
value.to_d
when Integer
value.to_s.to_d
else
raise Sequel::Error::InvalidValue, "invalid value for BigDecimal:
#{value.inspect}"
end
when :boolean
case value
when false, 0, "0", /\Af(alse)?\z/i
false
else
value.blank? ? nil : true
end
when :date
case value
when Date
value
when DateTime, Time
Date.new(value.year, value.month, value.day)
when String
value.to_date
else
raise Sequel::Error::InvalidValue, "invalid value for Date:
#{value.inspect}"
end
when :time
case value
when Time
value
when String
value.to_time
else
raise Sequel::Error::InvalidValue, "invalid value for Time:
#{value.inspect}"
end
when :datetime
raise(Sequel::Error::InvalidValue, "invalid value for Datetime:
#{value.inspect}") unless value.is_one_of?(DateTime, Date, Time, String)
if Sequel.datetime_class === value
# Already the correct class, no need to convert
value
elsif value.is_a?(DateTime)
value.strftime("%Y-%m-%d %H:%M:%S")
elsif value.is_a?(String)
value # Risky! FIXME
else
# First convert it to standard ISO 8601 time, then
# parse that string using the time class.
(Time === value ? value.iso8601 : value.to_s).to_sequel_time
end
when :blob
value.to_blob
else
value
end
end
#------------ END ------------
--
James Britt
www.happycamperstudios.com - Wicked Cool Coding
www.jamesbritt.com - Playing with Better Toys
www.ruby-doc.org - Ruby Help & Documentation