Ugh. If Open needs a flag, pass it a flag.
Russ
The others were too complicated for me to understand.
It's possible they provide important functionality that this
one does not, but so far it has worked well for me.
Here is a simple test program.
Russ
package main
import (
"log"
"os"
"gosqlite.googlecode.com/hg/sqlite"
)
func errchk(err os.Error) {
if err != nil {
log.Exit(err)
}
}
func main() {
db, err := sqlite.Open("foo.db")
errchk(err)
db.Exec("DROP TABLE pages")
errchk(db.Exec("CREATE TABLE pages (number, title, text, revid)"))
errchk(db.Exec("INSERT INTO pages (number, title) VALUES (?, ?)",
"ABC", "alphabet"))
errchk(db.Exec("INSERT INTO pages (number, title) VALUES (?, ?)", 123, "456"))
stmt, err := db.Prepare("SELECT title FROM pages WHERE number = ?")
errchk(err)
var t string
errchk(stmt.Exec("ABC"))
if !stmt.Next() {
log.Stdout("no match for ABC")
}
errchk(stmt.Scan(&t))
log.Stdout("ABC: ", t)
var i int
errchk(stmt.Exec("123"))
if !stmt.Next() {
log.Stdout("no match for 123")
}
errchk(stmt.Scan(&i))
log.Stdout("123: ", i)
stmt.Finalize()
}
On Sat, 2010-05-29 at 14:31 -0700, Russ Cox wrote:
> I've never used sqlite before, but I was playing with it the
> other night and wrote a new, very simple binding for it.
> http://code.google.com/p/gosqlite/
>
> The others were too complicated for me to understand.
> It's possible they provide important functionality that this
> one does not, but so far it has worked well for me.
Having the connection and the method for sending SQL is just the
beginning. On top of this is needed a more native way of handling
queries. In Python, Java, Groovy, etc. you get some form of object
relational mapping. Whether such a thing is desirable for Go per se is
a moot point due to the very different way Go deals with the concept of
object. However having the higher level of abstraction should not be in
doubt.
Groovy has an interesting take in the middle ground between DB API and
ORM in that it allows Groovy code to be used to represent the SQL that
is then constructed via a builder. For example:
#! /usr/bin/env groovy
import groovy.sql.Sql
import Data
sql = Sql.newInstance ( Data.databaseName , Data.databaseDriver )
sql.dataSet ( 'items' ).findAll { it.sex == 'Male' && it.location == 'London' && it.maritalStatus == 'Single' }.each { println ( it.name ) }
I guess this is the same direction that LINQ and PLINQ are taking C#,
but that is an external rather than internal DSL I believe.
Groovy and Python are dynamic languages with MOPs, which means it can
all be handled as an internal DSL. Go may not have the capability of
handling this as an internal DSL.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
In my (albeit limited) experience, ORMs can definitely be a pain in
the ass, often more trouble than they're worth. Why is it considered a
"needed" "feature" in a DB API? What's insufficient about binding
variables directly?
In my unfortunately rather extensive experience, ORMs are invariably a
huge pain in the ass. They make debugging and performance optimization
talks a nightmare, and while I'm not big fan of SQL databases, ORMs
tend to hide or at best obstruct many of their most important
features.
If you can't or wont write SQL, you should not be using an SQL database.
uriel