[ANN] SQLite/Ruby 2.0.0 BETA

Jamis_Buck4 · 9 September 2004 19:15

SQLite/Ruby is an interface for Ruby into the SQLite database engine. It is only for SQLite version 2.x -- it does not (yet) support 3.x.

http://sqlite-ruby.rubyforge.org
http://rubyforge.org/projects/sqlite-ruby

This version is a completely rewrite of the original codebase. (Yes, you're probably sensing a pattern here... copland... then sqlite-ruby... the more I learn about Ruby, the more I realize that much of the code I wrote even a year ago could be done much more cleanly and concisely, and I so I'm working to fix those flaws.)

Futhermore, this is only a BETA RELEASE. It is probably not ready for production environments yet, since the API may change from release to release. I need people willing to put this release through its paces, to help me solidify it for a stable 2.1 release. If you're willing, go ahead and download it and start sending me suggestions (or submitting bug reports via the trackers on RubyForge).

So, the meat of this release:

* The previous release used the callback-based "sqlite_exec" API. This was fairly fragile from Ruby's perspective, since exceptions and the like could result easily in locked or busy databases. This release moves to the compile/step/finalize API, which does not use C callback functions. This makes it much easier to use both internal and external iterators for queries. It also makes the Ruby interface much more robust.

* "show_datatypes" is now always on (and cannot be changed), since it only applied to the "sqlite_exec" interface.

* Type translators are now registered per database instance, instead of globally. This allows multiple databases to exist with different translators for the same datatypes.

* The interface has been broken apart into Database/Pragma/Statement/ResultSet responsibilities.

* Better metadata querying.

* Better (and more) unit tests.

* Rows are returned as arrays by default, instead of hashes, but rows as hashes are still supported (see Database#results_as_hash).

Support for Ara's "arrayfields" module remains implicit. If you require the arrayfields module before doing a query, then the rows that returned may be indexed by column name (like a hash) or iterated through by index (like an array).

Lastly: some of you may be wondering why I still bother with the older 2.x interface for SQLite, given that the 3.x interface is almost out of beta. Three reasons: one, I'm familiar with it. Two, there are still alot of people that use 2.x databases. Three, a Ruby interface for SQLite3 is forthcoming--watch this space!

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

gabriele_renzi · 9 September 2004 19:30

Jamis Buck ha scritto:

SQLite/Ruby is an interface for Ruby into the SQLite database engine. It is only for SQLite version 2.x -- it does not (yet) support 3.x.

http://sqlite-ruby.rubyforge.org
http://rubyforge.org/projects/sqlite-ruby

This version is a completely rewrite of the original codebase.

Please, when the final version come out, could you make a mswin copy available somewhere?
(Actually, I'd have loved to see a DL based version, so that this was not needed at all, but this is OT

Ara.T.Howard6 · 9 September 2004 20:55

SQLite/Ruby is an interface for Ruby into the SQLite database engine. It
is only for SQLite version 2.x -- it does not (yet) support 3.x.

you are an animal jamis!

Support for Ara's "arrayfields" module remains implicit. If you require
the arrayfields module before doing a query, then the rows that returned
may be indexed by column name (like a hash) or iterated through by index
(like an array).

   thanks very much! for those of you wondering the sole intrusion into jamis'
   code is a check for a 'field=' method. eg. you could implement your own
   Array#fields= method and not use arrayfields.

Lastly: some of you may be wondering why I still bother with the older 2.x
interface for SQLite, given that the 3.x interface is almost out of beta.
Three reasons: one, I'm familiar with it. Two, there are still alot of
people that use 2.x databases. Three, a Ruby interface for SQLite3 is
forthcoming--watch this space!

i subscribe to the sqlite mailing list and read it often. 3 is definitely
not ready for production yet.

kind regards.

-a

···

On Fri, 10 Sep 2004, Jamis Buck wrote:
--

EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen

===============================================================================

Jamis_Buck4 · 9 September 2004 19:44

gabriele renzi wrote:

Jamis Buck ha scritto:

SQLite/Ruby is an interface for Ruby into the SQLite database engine. It is only for SQLite version 2.x -- it does not (yet) support 3.x.

http://sqlite-ruby.rubyforge.org
http://rubyforge.org/projects/sqlite-ruby

This version is a completely rewrite of the original codebase.

Please, when the final version come out, could you make a mswin copy available somewhere?
(Actually, I'd have loved to see a DL based version, so that this was not needed at all, but this is OT

I'd be happy to make a mswin version available somewhere, but I'll need someone else to prepare it. I do not have convenient access to a windows-based development environment.

If there is anyone that would be willing to work with me to coordinate a binary windows release of each future SQLite/Ruby version, please contact me off-list. Thanks!

- Jamis

···

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

Jamis_Buck4 · 9 September 2004 21:14

SQLite/Ruby is an interface for Ruby into the SQLite database engine. It
is only for SQLite version 2.x -- it does not (yet) support 3.x.

you are an animal jamis!

_Homo sapiens_, to be precise.

Support for Ara's "arrayfields" module remains implicit. If you require
the arrayfields module before doing a query, then the rows that returned
may be indexed by column name (like a hash) or iterated through by index
(like an array).

  thanks very much! for those of you wondering the sole intrusion into jamis'
  code is a check for a 'field=' method. eg. you could implement your own
  Array#fields= method and not use arrayfields.

Actually, I do a check to see if 'fields=' is already defined (by arrayfields, for example), and if is hasn't been, I define it. That way the interface is consistent, whether you're using arrayfields or not. Pretty similar to what I did for the last version.

Lastly: some of you may be wondering why I still bother with the older 2.x
interface for SQLite, given that the 3.x interface is almost out of beta.
Three reasons: one, I'm familiar with it. Two, there are still alot of
people that use 2.x databases. Three, a Ruby interface for SQLite3 is
forthcoming--watch this space!

i subscribe to the sqlite mailing list and read it often. 3 is definitely
not ready for production yet.

Good to know. I'll hold of a bit longer, then. It's not like I haven't got enough to do, after all!

kind regards.

-a

- Jamis

···

Ara.T.Howard@noaa.gov wrote:

On Fri, 10 Sep 2004, Jamis Buck wrote:

--
Jamis Buck
jgb3@email.byu.edu
http://www.jamisbuck.org/jamis

"I use octal until I get to 8, and then I switch to decimal."

Shashank_Date4 · 9 September 2004 20:21

Hi Jamis,

···

--- Jamis Buck <jgb3@email.byu.edu> wrote:

I'd be happy to make a mswin version available
somewhere, but I'll need someone else to
prepare it.

After modifying the sqlite-api.c includes slightly, I
tried compiling it using MSVC++ 6.0 (on WIn 2K PRO)
and I got link errors. (See below:)

So where is _sqlite_progress_handler and
_sqlite_commit_hook defined?

-- shanko
--------------------------------------------------
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\extract\_ruby\sqlite-ruby-2.0.0\ext>ruby extconf.rb
checking for main() in sqlite.lib... no
checking for sqlite.h... no

C:\extract\_ruby\sqlite-ruby-2.0.0\ext>ruby extconf.rb
checking for main() in sqlite.lib... yes
checking for sqlite.h... yes
checking for sqlite_open() in sqlite.lib... yes
creating Makefile

C:\extract\_ruby\sqlite-ruby-2.0.0\ext>nmake

cl -nologo -MD -Zi -O2b2xg- -G6 -I.
-Ic:/ruby/lib/ruby/1.8/i386-mswin32
-Ic:/ruby/lib/ruby/1.8/i386-mswin32 -I.
-DHAVE_SQLITE_H -I. -I./.. -I./../missing -c
-Tcsqlite-api.c
sqlite-api.c
sqlite-api.c(34) : fatal error C1083: Cannot open
include file: 'unistd.h': No such file or directory
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

C:\extract\_ruby\sqlite-ruby-2.0.0\ext>nmake

        cl -nologo -MD -Zi -O2b2xg- -G6 -I.
-Ic:/ruby/lib/ruby/1.8/i386-mswin32
-Ic:/ruby/lib/ruby/1.8/i386-mswin32 -I.
-DHAVE_SQLITE_H -I. -I./.. -I./../missing -c
-Tcsqlite-api.c
sqlite-api.c
        c:\ruby\bin\ruby -e "puts 'EXPORTS',
'Init_sqlite_api'" > sqlite_api-i386-mswin32.def
        cl -nologo -LD -Fesqlite_api.so sqlite-api.obj
msvcrt-ruby18.lib sqlite.lib sqlite.lib oldnames.lib
user32.lib advapi32.lib wsock32.lib -link
-incremental:no -debug -opt:ref -opt:icf -dll
-libpath:"c:/ruby/lib"
-def:sqlite_api-i386-mswin32.def
   Creating library sqlite_api.lib and object
sqlite_api.exp
sqlite-api.obj : error LNK2001: unresolved external
symbol _sqlite_progress_handler
sqlite-api.obj : error LNK2001: unresolved external
symbol _sqlite_commit_hook
sqlite_api.so : fatal error LNK1120: 2 unresolved
externals
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.

C:\extract\_ruby\sqlite-ruby-2.0.0\ext>

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

Justin_Rudd · 9 September 2004 23:45

After modifying the sqlite-api.c includes slightly, I
tried compiling it using MSVC++ 6.0 (on WIn 2K PRO)
and I got link errors. (See below:)

So where is _sqlite_progress_handler and
_sqlite_commit_hook defined?

sqlite_progress_handler and sqlite_commit_hook aren't exported in the
pre-built Windows DLL. I built my own version of SqlLite (that also
removes the dependency on MSVCRT.dll), linked it against SqlLite/Ruby
2.0.0 beta and all is well.

Good news is...this one only took me about a half an hour. Guess the
6 hours I spent on MySQL this morning paid off.

I'll send the DLL to Jamis so he can put in the project. Let me know
if you have any issues with it. I didn't test it extensively (time
constraints...wife came home...gotta spend time with the wife :))

···

--
Justin Rudd
http://seagecko.org/thoughts/

Topic		Replies	Views
[ANN] SQLite/Ruby 1.2.9.1 ruby-talk	0	119	4 July 2004
[ANN] SQLite/Ruby 2.2.0 ruby-talk	1	113	28 October 2004
[ANN] SQLite/Ruby 2.2.0 ruby-talk	4	119	1 November 2004
[ANN] SQLite/Ruby 2.0.1 BETA ruby-talk	15	128	12 September 2004
[ANN] SQLite-Ruby 1.3.0 ruby-talk	14	132	13 July 2004

[ANN] SQLite/Ruby 2.0.0 BETA

On Fri, 10 Sep 2004, Jamis Buck wrote: --

Related topics

On Fri, 10 Sep 2004, Jamis Buck wrote:
--