dbf.py API question
Ethan Furman
ethan at stoneleaf.us
Fri Aug 3 09:11:59 EDT 2012
Peter Otten wrote:
> 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.
So far all feedback is for the flag, so that's what I'll do.
> 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.
Seems like that would be quite a slow-down (although if a user wants to
do that, s/he certainly could).
> - Are names required to manipulate the table? If not you could just omit
> them to make the table "in-memory".
At one point I had thought to make tables singletons (so only one copy
of /user/bob/scores.dbf) but that hasn't happened and is rather low
priority, so at this point the name is not required for anything beside
initial object creation.
> - How about a connection object that may either correspond to a directory or
> RAM:
>
> db = dbf.connect(":memory:")
> table = db.Table("foo", ...)
dbf.py does not support the DB-API interface, so no connection objects.
Tables are opened directly and dealt with directly.
All interesting thoughts that made me think. Thank you.
~Ethan~
More information about the Python-list
mailing list