Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #26421
| From | Peter Otten <__peter__@web.de> |
|---|---|
| Subject | Re: dbf.py API question |
| Date | 2012-08-03 11:03 +0200 |
| Organization | None |
| References | <501AA304.3090000@stoneleaf.us> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.2894.1343984571.4697.python-list@python.org> (permalink) |
Ethan Furman wrote:
> SQLite has a neat feature where if you give it a the file-name of
> ':memory:' the resulting table is in memory and not on disk. I thought
> it was a cool feature, but expanded it slightly: any name surrounded by
> colons results in an in-memory table.
>
> I'm looking at the same type of situation with indices, but now I'm
> wondering if the :name: method is not pythonic and I should use a flag
> (in_memory=True) when memory storage instead of disk storage is desired.
For SQLite it seems OK because you make the decision once per database. For
dbase it'd be once per table, so I would prefer the flag.
Random
> Thoughts?
- Do you really want your users to work with multiple dbf files? I think I'd
rather convert to SQLite, perform the desired operations using sql, then
convert back.
- Are names required to manipulate the table? If not you could just omit
them to make the table "in-memory".
- How about a connection object that may either correspond to a directory or
RAM:
db = dbf.connect(":memory:")
table = db.Table("foo", ...)
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: dbf.py API question Peter Otten <__peter__@web.de> - 2012-08-03 11:03 +0200
csiph-web