[postgis-devel] Common Code

[Mark Cave-Ayland]

On 09/08/11 17:58, Bryce L Nordgren wrote:

> The thing that gives me pause is making a generic caching facility in a
> language like C. Polymorphism is really hard in that environment, as
> indicated by the lack of generic caching libraries in C. The hard part
> is not necessarily just storing the pointer to an opaque type, but
> figuring out whether you have a cache hit or not. Sounds like a
> pandora's box to me.

Opaques aren't really an issue since if we move these into liblwgeom 
then the cache code path will get tested as part of the CUnit tests and 
so we'd know immediately if these broke. Since only developers get to 
see these low level parts of the project, I think this is reasonable.

Perhaps I've not explained it very well, but the use of a key/value 
store is related into the slightly hacky way in which we use the 
PostgreSQL memory contexts to handle context pointers and free 
themselves as part of the memory cleanup process. It's not a 
specifically a key/value store that we are looking for.

> What about using BerkeleyDB in a RAM only configuration as a key/value
> store? It's mature, stable, and multiplatform.

Eh you are joking, right? I'm currently involved with 2 major 
open-source projects that use BDB. The first got so fed up with it that 
they wrote their own implementation that was significantly faster than 
BDB, while the second has release notes that read along the lines of: 
you can use versions 4.2, 4.4, 4.5.7-4.5.10, 4.6 > 4.6.5 and so on, 
otherwise you will experience data loss under load. This is not the 
hallmark of either a particularly mature or stable project.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs