[pacman-dev] [PATCH] small fix in bindings directory

[Roman Kyrylych]

2006/10/26, Aaron Griffin <aaronmgriffin at gmail.com>:
> On 10/26/06, Roman Kyrylych <roman.kyrylych at gmail.com> wrote:
> > [offtopic on]
> > BTW, about complex patches - I have a patch from Martin Devera that
> > adds support for gdbm database backend to pacman 2.9.8. I suggested
> > him to contact VMiklos for help in inclusion it in pacman, but I don't
> > know if he did that. If I adapt it for Pacman 3 API is there a chance
> > it will be included at least in CVS/DARCS?
> > [/offtopic off]
>
> There's no chance that would get included in pacman 2.9.8 - it will die soon.
>
> Converting it to pacman3 is entirely doable and it's already setup to
> do so.  You should be able to copy be_files.c to be_gdbm.c and consume
> the interface provided there.
>
> FTR 'be_' means 'backend'.  I still need to add compile-time flags for
> selecting a backend, but as we only provide _files at the moment,
> there's no need.
>
> I worked on a 'compressed' backend that required no changes, but read
> directly from the downloaded db files... it caused problems on the
> local db, however, so I never completed it (yet).
>
> As for backend schemes, I think we need to discuss avenues of attack
> here.  The files backend is painfully slow on ext filesystems (11
> seconds to parse [community]).  There are many users touting a
> database backend as a good idea (I highly disagree), and if we do
> this, we NEED a generic layer to support any sane database format, not
> just one specific thing.  Using a flat-file database is a better
> option, but here people seem to think sqlite is a good idea (it's not)
> - there are many flat-file schemes that can drastically outperform
> sqlite.
>
> There are many many other options, and I think it's worth at least
> _supplying_ multiple backends, even if they're not used.  So gdbm is
> cool.

Maybe we should start separate thread for this?
Personally, I think sqlite will be the best choice because of:
1) it's small
2) it's fast
3) it's embedable
4) it offers full power of SQL99 (with ACID transactions!!!)
5) it's public domain! :-D

-- 
Roman Kyrylych (Роман Кирилич)