FAQ
Hi. I still don't have enough time to fix things (sorry)
but confirmed that the new collation_needed implementation
doesn't leak any more. It may be worth a new dev release.

Thanks,

Kenichi
On Thu, 6 Aug 2009 16:34:53 +0200, "Dami Laurent (PJ)" wrote:

Hi folks,

For info, I just committed a new implementation for "collation_needed",
that no longer uses dynamic memory allocation, and therefore should no
longer leak. The extra information needed is just an additional field in
the imp_dbh_st struct (this makes sense because at any point in time, a
dbh cannot have more than one "collation_needed" handler -- I should
have realized that in the first place!).

To address Adam's argument about global registry, I first thought of a
bunch of methods "register_global_collation", "list_global_collations",
etc., that would hide the internal hash implementation. But the API
became heavy, and finally it seemed more perlish to expose that stuff
as a regular hash, so that clients can use all Perl idioms for hashes
--- except that this is a "write-once" hash : any attempt to modify or
delete an existing entry raises an exception. Hackers who for any
obscure reason would need to override an existing entry can always use
the 'tied' API -- but then there is really no risk of doing it
accidentally.

The doc has been adapted in consequence.

I hope these solutions are satisfactory to everyone.

Greetings, Laurent Dami
_______________________________________________
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite

Search Discussions

Discussion Posts

Previous

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
groupdbd-sqlite @
postedAug 6, '09 at 2:34p
activeAug 10, '09 at 4:19p
posts2
users2
websiteshadowcat.co.uk

People

Translate

site design / logo © 2021 Grokbase