been running since with no problems using the new serialization
mechanisms. I am happy to
in your changes to support the delete() feature for
OK - have code written. I'm running unit
My code was written against code *prior* to
Bryan's major overhaul of the serialization mechanism. Do we have any
solid experience with this new code? Is it 100% backwards
compatible? There's an aweful lot of lines changed...
I need to get this deletion capability into
a production environment, and I'm a bit nervous of also releasing the new
serialization facility... I don't think we want to get into branching
the code base either... I'm perfectly happy to keep this code on my
system and not release it into HEAD for the time being if that's the best way
to approach this.
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes searching
your log files as easy as surfing the web. DOWNLOAD SPLUNK!
_______________________________________________ Jdbm-developer mailing list
That's pretty much
how I would go about it.
Kevin Day wrote:
wanted to follow up on something Bryan mentioned last week:
> now, there is no way to delete a BTree.
You can delete the root, but
> that won't delete any of the
> I have an immediate need for doing this
kind of deletion in my
> application, and I'm wondering if you
guys have any preferences on how
> to add this...
> Here is what I'm thinking about doing:
> 1. Add an instance method delete() to BTree
2. Add an instance method delete() to BPage
> 3. Have
BTree call delete on all of it's children recursively, then
> The recman will be assocaited with
the BTree already (via the statis
> load() method), so I don't
think we need to pass that in again.
> Does anyone have any objections to the above strategy, or
is there a
> better approach that I haven't thought of?