Retrieving last modified node path (Was: [augeas-devel] First tests with aug mv)

[Raphaël Pinson]

On Fri, Aug 1, 2008 at 7:41 PM, David Lutterkort <dlutter at redhat.com> wrote:

> On Fri, 2008-08-01 at 11:14 +0200, Raphaël Pinson wrote:
>
>
> > After talking with David on IRC, I now understand that modifying
> > tree_insert to return the path to the created node would mean to
> > modify the API, which is not acceptable. David proposes another
> > approach, which would be to store the path to this new node
> > in /augeas/last_created_node.
>
> Thanks for bringing this up on the list - definitely better to discuss
> this here. The only change I would make to what we talked on IRC is to
> put that info a little deeper in the tree, like put it
> at /augeas/tree/last_created (mostly for cosmetic reasons)
>
> > After thinking about this, I think a /augeas/last_modified_node would
> > actually be more useful, although the most obvious use of it would be
> > for insert.
> >
> > With insert, this is an obvious need :
> > aug_ins("field", "after", path) does not give me any information on
> > the node that was created, so I have no clue on what path to pass to
> > aug_set or aug_rm if I want to set or remove this node.
> >
> > On the other hand, 'aug_set("/files/etc/my/file/field[100]", "value")'
> > or 'aug_set("/files/etc/my/file/field[last()]", "value")' do not give
> > me any information either on the exact path to the node I just
> > modified, but contrarily to aug_insert, I can still refer to this
> > modified node as "/files/etc/my/file/field[100]" or
> > "/files/etc/my/file/field[last()]".
> >
> > I think it could be interesting to have a /augeas/last_modified_node
> > where every function (whether insert, set, rm, mv, etc.) would write
> > the name of the last modified node, so that the user can retrieve it
> > to reuse it:
>
> I like that idea a lot. Just thinking out loud, here's what a call to
> aug_get(aug, "/augeas/tree/last_modified", &p) after each API call would
> set teh variable p to:
>
>   Previous call    p (the modfied path)
>        aug_init     - NULL
>        aug_get      - no influence on value
>        of /augeas/tree/last_modified
>        aug_set      - PATH passed to aug_set, fully qualified
>        aug_insert   - fully qualified path to newly created node
>        aug_rm       - PATH passed to aug_rm
>        aug_mv       - PATH passed to aug_mv as DST argument
>        aug_match    - no influence on value of /augeas/tree/last_modified
>        aug_save     - either leave /augeas/tree/last_modified unchanged or
> set to NULL
>        aug_print    - no influence on value of /augeas/tree/last_modified
>


I was more thinking of using the PATH resulting of the action instead of the
path passed to the API (in the case of set for example, thinking about
/files/some/path/to/field[100])...


> Some more notes:
>      * you can use the return value of an aug_get on
>        "/augeas/tree/last_modified" right after aug_init to see if that
>        feature is supported in your version of Augeas - return of '0'
>        means no, return of 1 means 'yes'
>      * the path expression passed to aug_rm can actually specify more
>        than one node (like 'rm /files/etc/hosts/*')
>

... but there I understand better why you would use the sent PATH instead.



>      * you still can't tell whether aug_set actually created a node or
>        modified an existing node - that could be fixed by changing the
>        return value of aug_set, e.g. return 0 when an already existing
>        node was modified, and 1 when the node had to be created first
>      * should aug_save clear /augeas/tree/last_modified or leave it
>        alone ?
>      * Looking at the table above, I don't think a last_modified entry
>        would buy us much over a last_created entry; the last_created
>        entry would only be changed by aug_set, aug_mv and aug_insert
>        and would be guaranteed to always refer to exactly one node


I don't quite understand what you mean by this.


Raphael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/augeas-devel/attachments/20080801/619f08d9/attachment.htm>