[dev] Major flaw in DataTree::getLast() implementation
Chuck Hagenbuch
chuck at horde.org
Sat May 28 11:47:10 PDT 2005
Quoting Jan Schneider <jan at horde.org>:
> It took me a while to find this out, but it's easy to reproduce: simply
> start a new thread in Agora and return to the forums listing directly
> after that.
>
> DataTree::getLast() assumes that the last object in a tree branch is
> the one with the highest ID. But that's wrong because in add() we
> *first* retrieve a new sequence ID and *then* check if we already have
> a parent object and create it if not (retrieving another, higher
> sequence ID). This logic could probably be changed in add(), but it
> exists since ever, so getLast() won't work with any old DataTree data,
> which is a bad thing IMO.
>
> Any ideas how to proceed?
I remember wondering about the implementation when it was first
proposed. Looking at the schema I don't think there's any way it can
work reliably as-is. We'd need to either reorder existing ids and
change add(), or add a new field - datatree_updated won't work because
if an existing row is touched, it'll get updated and suddenly be "last".
With adding a new field we could create a very arbitrary script to
assign values that'd work for old data, sort of walking the tree... I
don't think it'd hurt to add datatree_created and start using
datatree_updated explicitly. Or we can just drop datatree_updated from
the schema since we don't use it - wouldn't hurt to have less data in
that table.
Thinking further, we can't reorder existing data because it might break
applications using getById().
We can make it work for future data, but not existing data - I don't
think there's a way around it.
-chuck
--
"But she goes not abroad in search of monsters to destroy." - John
Quincy Adams
More information about the dev
mailing list