Persisting SCM field (Or how does persistence work?)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Persisting SCM field (Or how does persistence work?)

digerata-3
Kohsuke or someone with more knowledge on Hudson persistence:

I have a field that doesn't appear to survive restarts in the
PerforceSCM class.  It tracks the last change list number that Hudson
has sync'd to.  Because it is not saved across restarts, the first build
after startup contains all changes up to that point.  Now, there are
getter/setter methods for this field.  However, the constructor does not
have a parameter for this value.

My first impression was that the constructor was only used for initial
setup of the object.  In this case, the first time PerforceSCM was
configured.  That is why I didn't provide a parameter to the constructor
for this field.  Given this problem, I think I missed something.  Does
Hudson persistence use the getter/setter methods or does it use the
constructor?

Thanks for any insight you can provide!

-Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Persisting SCM field (Or how does persistence work?)

Kohsuke Kawaguchi
Administrator
Mike Wille wrote:
> Kohsuke or someone with more knowledge on Hudson persistence:
>
> I have a field that doesn't appear to survive restarts in the
> PerforceSCM class.

Which field? You don't appear to have any transient field so it should
all survive.

 > It tracks the last change list number that Hudson
> has sync'd to.

Ah, 'lastChange'.

 > Because it is not saved across restarts, the first build

> after startup contains all changes up to that point.  Now, there are
> getter/setter methods for this field.  However, the constructor does not
> have a parameter for this value.
>
> My first impression was that the constructor was only used for initial
> setup of the object.  In this case, the first time PerforceSCM was
> configured.  That is why I didn't provide a parameter to the constructor
> for this field.  Given this problem, I think I missed something.  Does
> Hudson persistence use the getter/setter methods or does it use the
> constructor?
Persistence works like Java serialization, in that it captures all the
fields, regardless of their access modifiers.

PerforceSCM object is stored in job's config.xml, which is only saved
when you do "AbstractProject.save()" So when you update this field (you
have two places but I recommend changing line 191 to call
setLastChange), you need to call build.getParent().save() to trigger the
save operation.

That said, I think a better approach here is to obtain the lastChange
value by looking at the PerforceTagAction object of the last build,
because that's what you really want to compare against.

Also, SCM object is generally a place for storing configuration
information, and not designed for storing information that changes from
builds to builds.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Persisting SCM field (Or how does persistence work?)

digerata-3
Kohsuke Kawaguchi wrote:

> Mike Wille wrote:
>> Kohsuke or someone with more knowledge on Hudson persistence:
>>
>> I have a field that doesn't appear to survive restarts in the
>> PerforceSCM class.
>
> Which field? You don't appear to have any transient field so it should
> all survive.
>
> > It tracks the last change list number that Hudson
>> has sync'd to.
>
> Ah, 'lastChange'.
>
> > Because it is not saved across restarts, the first build
>> after startup contains all changes up to that point.  Now, there are
>> getter/setter methods for this field.  However, the constructor does
>> not have a parameter for this value.
>>
>> My first impression was that the constructor was only used for
>> initial setup of the object.  In this case, the first time
>> PerforceSCM was configured.  That is why I didn't provide a parameter
>> to the constructor for this field.  Given this problem, I think I
>> missed something.  Does Hudson persistence use the getter/setter
>> methods or does it use the constructor?
>
> Persistence works like Java serialization, in that it captures all the
> fields, regardless of their access modifiers.
Makes sense...
>
> PerforceSCM object is stored in job's config.xml, which is only saved
> when you do "AbstractProject.save()" So when you update this field
> (you have two places but I recommend changing line 191 to call
> setLastChange), you need to call build.getParent().save() to trigger
> the save operation.
>
Doh, I remember that snuck up on me with tagging...  That all makes
sense.  It is now sticky noted to my forehead!
> That said, I think a better approach here is to obtain the lastChange
> value by looking at the PerforceTagAction object of the last build,
> because that's what you really want to compare against.
>
> Also, SCM object is generally a place for storing configuration
> information, and not designed for storing information that changes
> from builds to builds.
>
Totally, makes sense.  And what do you know...  There is a
project.getPreviousBuild()!  :)

Quick question though.  I added the check to getPreviousBuild() to
lookup the PerforceTagAction and the change number for it.  My initial
thought was that I can forgo the call to build.getParent().save()
because I'm no longer storing that value within the SCM object.  
However, what happens for the following code:

// within SCM.checkout() method
//...
build.addAction(new PerforceTagAction(build, depot, lastChange,
projectPath));

Is the PerforceTagAction persisted with build.addAction()?  It seems
like it is persisted from past experience.  (At least the tag action was
available after I restarted.)  But that would mean there is an implicit
save() going on somewhere.  Some of my confusion stems from that.  Where
are the implicit saves and does explicitly saving a project also save
all of its dependent objects like builds?  I suppose the answer to that
could turn into a very in depth response.  So really, if you can just
answer on whether or not there are implicit saves going on?

Thanks for the advice and any further clarification!

-Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Persisting SCM field (Or how does persistence work?)

Kohsuke Kawaguchi
Administrator
Mike Wille wrote:

> Quick question though.  I added the check to getPreviousBuild() to
> lookup the PerforceTagAction and the change number for it.  My initial
> thought was that I can forgo the call to build.getParent().save()
> because I'm no longer storing that value within the SCM object.  
> However, what happens for the following code:
>
> // within SCM.checkout() method
> //...
> build.addAction(new PerforceTagAction(build, depot, lastChange,
> projectPath));
>
> Is the PerforceTagAction persisted with build.addAction()?  It seems
> like it is persisted from past experience.
Maven should have downloaded Hudson core source jar for your IDE,
precisely so that you can check the source code to get answers for
questions like this. The addAction method is implemented as:

     public void addAction(Action a) {
         getActions().add(a);
     }

an hence it actually doesn't save.


 > (At least the tag action was
> available after I restarted.)  But that would mean there is an implicit
> save() going on somewhere.  Some of my confusion stems from that.

I actually don't know for sure where all save()s happen --- that's also
an IDE job to figure out, but I know a build is saved when it's
completed, so if you add an action during SCM operations, it will be
persisted some point later.

 > Where
> are the implicit saves and does explicitly saving a project also save
> all of its dependent objects like builds?

Save is per file, so saving a project only saves config.xml of the
project and nothing else.

 > I suppose the answer to that
> could turn into a very in depth response.  So really, if you can just
> answer on whether or not there are implicit saves going on?

No, there's no implicit saves going on. They are all explicit calls to
save(). But you are right that it's hard to see where all the save()
invocations happen.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment