Ed Leafe wrote: > On Nov 23, 2008, at 9:42 PM, Paul McNett wrote: > >> You are proving my point. >> >> With SQLite, the connection name becomes the database name. You get >> one database per >> connection. With other databases, you get a connection that can have >> several databases. > > Actually, I don't think you are understanding my point.
Actually, we are (mostly) agreeing but I guess using different terms. > A connection is to a server, not to a database. Agreed. > With a server like > MySQL, passing the database in the connect string is a shortcut for > connecting to the server and then setting the db as the current > namespace. While this gets muddy with file-based backends, the > "server" in this case is the file. The problem with SQLite is that > it's creating *servers* on the fly, not databases. No, the file isn't the server; the file is the database. The sqlite program is "server". This is just the same as in MySQL: the server is the thing running on port 3506 or whatever; the database is the directory that lives in /var/local/db/mysql or whatever. The only real difference is that the sqlite "server" requires a database name in the connect() function, and will create the *database* if it doesn't exist. The sqlite database file doesn't, in itself, serve anything. That's what the sqlite program does. > I have this on my to-do list for tonight. Preventing file creation is > easy; I have to now find all the UI hooks that need to catch that > error and relay it to the user. Cool, but I still wonder how wise it is to relay this kind of stuff nicely to the user, as it isn't something they'd likely be able to deal with anyway. It should IMO be relayed normally as a traceback so the appdev can take care of it. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
