Refactor of rtree.index.Index

[Sean Gillies-2]

The Index class's __init__ method does different things depending on  
whether it's been passed a filename name parameter or not. IMO,  
different classes for disk or memory indexes will make for cleaner  
code, and also make it easier to implement storage-dependent features  
like the sync() method I am planning (syncs the live and persisted  
states of the index).

I propose:

* a not-to-be-instantiated IndexBase class, which is the current Index  
class minus storage-specific code in __init__

* a MemoryIndex class

* a DiskIndex class with disk storage-specific initialization code,  
open(), close(), and sync() methods

I considered separating storage out as a class, but I don't see a use  
case for switching storage once the index has been created.

--
Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Howard Butler-3]

On Sep 16, 2009, at 5:43 AM, Sean Gillies wrote:

> The Index class's __init__ method does different things depending on
> whether it's been passed a filename name parameter or not. IMO,
> different classes for disk or memory indexes will make for cleaner
> code, and also make it easier to implement storage-dependent features
> like the sync() method I am planning (syncs the live and persisted
> states of the index).
>

Would the convenience this afforded to the rtree.Rtree class continue  
to exist?  I doubt there's much code depending on rtree.index.Index's  
behavior wrt filenames, but there probably is for rtree.Rtree.

> I propose:
>
> * a not-to-be-instantiated IndexBase class, which is the current Index
> class minus storage-specific code in __init__
>
> * a MemoryIndex class
>
> * a DiskIndex class with disk storage-specific initialization code,
> open(), close(), and sync() methods

Sounds ok to me.

>
> I considered separating storage out as a class, but I don't see a use
> case for switching storage once the index has been created.

Not currently possible with libspatialindex unless you were to walk  
all of the leaf nodes of the tree and reinsert into the new storage.
_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community

[Sean Gillies-2]

On Sep 16, 2009, at 4:18 PM, Howard Butler wrote:

>
> On Sep 16, 2009, at 5:43 AM, Sean Gillies wrote:
>
>> The Index class's __init__ method does different things depending on
>> whether it's been passed a filename name parameter or not. IMO,
>> different classes for disk or memory indexes will make for cleaner
>> code, and also make it easier to implement storage-dependent features
>> like the sync() method I am planning (syncs the live and persisted
>> states of the index).
>>
>
> Would the convenience this afforded to the rtree.Rtree class continue
> to exist?  I doubt there's much code depending on rtree.index.Index's
> behavior wrt filenames, but there probably is for rtree.Rtree.
>
>> I propose:
>>
>> * a not-to-be-instantiated IndexBase class, which is the current  
>> Index
>> class minus storage-specific code in __init__
>>
>> * a MemoryIndex class
>>
>> * a DiskIndex class with disk storage-specific initialization code,
>> open(), close(), and sync() methods
>
> Sounds ok to me.

Cool. In answer to your question, I'll replace the rtree.Rtree class  
with a factory function and move the conditional code there.

>
>>
>> I considered separating storage out as a class, but I don't see a use
>> case for switching storage once the index has been created.
>
> Not currently possible with libspatialindex unless you were to walk
> all of the leaf nodes of the tree and reinsert into the new storage.

Okay.

--
Sean

_______________________________________________
Community mailing list
Community@...
http://lists.gispython.org/mailman/listinfo/community