flags for sqlite
Alfred Tarski
http://github.com/phf/go-sqlite3
I am trying to create an sqlite database file using
nsc, e := sqlite3.Open("d3.db?flags=0x00000006")
which (if I understand the docs correctly) should open an existing
file or create one if there is none to open.
Instead, I get a runtime message
error: parsing 0x00000006: invalid argument
I also tried
nsc, e := sqlite3.Open("sqlite3://d3.db?flags=0x00000006")
which leads to this runtime error:
error: Open: no path or database name
So there is something funky with the parsing ... any ideas?
Russ Cox
Ugh. If Open needs a flag, pass it a flag.
Russ
Archos
`openCreate`.
[1] http://github.com/phf/go-sqlite3/blob/master/core_test.go
Russ Cox
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.
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()
}
Kees
On May 30, 9:31 am, Russ Cox <r...@golang.org> wrote:
> I've never used sqlite before, but I was playing with it the
di
Russel Winder
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
Peter Bourgon
> 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.
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?
Uriel
> On Sun, May 30, 2010 at 2:08 PM, Russel Winder <rus...@russel.org.uk> wrote:
>> 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.
>
> In my (albeit limited) experience, ORMs can definitely be a pain in
> the ass, often more trouble than they're worth.
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
