[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [smila-dev] ParentId needed for DeltaIndexing of Compound records
- From: <Juergen.Schumacher@xxxxxxxxxxx>
- Date: Tue, 2 Jun 2009 08:57:10 +0200
- Delivered-to: firstname.lastname@example.org
- Thread-index: AcngceYUs8AZQYv3RI23carh7+LligC3MAKQ
- Thread-topic: [smila-dev] ParentId needed for DeltaIndexing of Compound records
> Could we just add a method getParentId() to interface Id and provide an
> appropriate implementation in IdImpl ?
> Is it even possible to implement this logic to compute a parentId from
> a given Id? How to handle elements and fragments ?
I think, the method Id.createCompundId() already does what you are looking
for. It creates a new ID object by removing the final fragment name, if fragments
exists, or the final element key, else. But it throws an exception instead
of returning null, if the current Id does not have a parent.
> Another option would be to include an optional parentId in the record.
> So we would have to either convert the id to xml and handle it as a
> String literal or an attachment. But this involves unneccessary
> conversion and parsing.
> So if this is the way to go I would prefer a special record member
> variabel parentId, that may be optionally set.
> Of course we could also add a parentId member to the Id object, so we
> don't have to recompute it.
I wouldn't want to add more members now. The computation of the compound/
parent Id is not complicated and probably not done very often, so I see
no reason to spend more memory on it. If that changes, we can still add
caching later, as it doesn't change the interface.