I remember a suggestion a while ago to let people write SQLite URL's like "sqlite://localfile.db" for files in the local directory, and "sqlite:///home/rmunn/example.db" for files with an absolute path, since people seemed to forget that they needed *four*, not three, slashes for an absolute path. I thought that proposal was a bad idea, since it would mean that "sqlite:///localfile.db" (the RFC1738-correct way to write a URL for a file in the local directory) would change its meaning and previously-correct code would start failing with "/localfile.db not found" errors.
Well, yesterday as I was working on some example code using an SQLite database, I found myself trying to write a URL like "sqlite:example.db" for a database in the working directory -- no slashes at all. That got me thinking: what if we allowed the user to leave off *precisely* three slashes from SQLite URL's? Local files would then become "sqlite:localfile.db", and absolute paths would look like "sqlite:/home/rmunn/example.db". In-memory databases present a slight problem since "sqlite::memory:" looks ugly and people *will* forget the second colon -- but "sqlite:///:memory:" would still work, and we could possibly allow the "sqlite://" form as well. Pros: It's unambiguous. "sqlite:localfile.db" and "sqlite:/home/rmunn/example.db" are totally plain. Cons: It's not RFC-1738 compliant, and would require some changes to the regexp in engine/url.py to make this possible. (The regexp currently looks for "(name)://", and would need to be changed to make the "//" optional. Either that, or add special-case logic to hand URLs starting with "sqlite:" off to a different parser.) The gain might not be worth the pain. Anyone have any thoughts on this? Would allowing "sqlite:/home/rmunn/example.db" be worth the pain of adding special-case logic, or are most people happy with the current status of SQLite URLs? -- Robin Munn [EMAIL PROTECTED] GPG key 0xD6497014 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~----------~----~----~----~------~----~------~--~---
