[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Diffing nested tables
- From: Martin Felis <martin@...>
- Date: Thu, 19 Sep 2013 09:20:18 +0200
I wrote general table diff and patch functions that also deals with
nested tables. It may not be the fastest but it still might be of use.
You can find it here:
On 18.09.2013 22:16, Marc Lepage wrote:
> Thanks for the suggestion.
> What I originally wanted was a way to alter a single table T (such that
> it has before and after like T1 and T2) but still be able to later go
> through it and know which entries were new and which were deleted. This
> is so I can perform some other changes related to each entry, depending
> on whether they were newly added or not. (These other changes could not
> occur as I went).
> In the meantime, I had the two tables (old one, and a fresh new one) and
> was reconciling them (figuring out which entries were only in the before
> or after table). I also tried a reference counting approach, but that
> required looping through them as well.
> However, finally I think I have an approach working with one table, and
> four states (never, new, untouched, and removed) which only requires one
> loop through at the end (to fix up all the entries to two states (absent
> and present) and do any actions accordingly. I still have to finish
> coding it tonight but I'm confident it will work.
> So I think I've sidestepped the problem nicely.
> On Wed, Sep 18, 2013 at 12:43 PM, Elias Barrionovo
> <email@example.com <mailto:firstname.lastname@example.org>> wrote:
> On Wed, Sep 18, 2013 at 1:01 AM, Marc Lepage <email@example.com
> <mailto:firstname.lastname@example.org>> wrote:
> > I could loop through all of T1 looking for entries not present in
> T2 (they
> > were removed), and then through all of T2 looking for entries not
> present in
> > T1 (they were added). But if nothing changed and there were a lot of
> > content, I'd be going through it twice for no real effect.
> > Better ideas?
> Well, I'm not sure if it's faster, since it may have more operations,
> but if T1 may be altered, you can do something like:
> For every value in T2, check if it exists in T1. If yes, then remove
> it from T1, if not, then you know it is new. Then whatever remains in
> T1 is what was deleted.
> If T1 must remain unchanged, you can create a copy of it and do the
> algorithm above, though I suspect the overhead of duplicating the
> table will be just the same - if not worse - then loop through both T1
> and T2.
> () - www.asciiribbon.org <http://www.asciiribbon.org>
> /\ - ascii ribbon campaign against html e-mail and proprietary