Re: [Ganymede Help] Help....

[Jonathan Abbey <jonabbey@arlut.utexas.edu>]

> HI JOn,
> I am now writing an external script for incrementing the serial number 
> for the zone. I have a question here....When i write a subclass of 
> ganymedeBuilderTask and in the method builderphase1() i say if 
> basechange((short) id) then it gives me a message every time the object 
> is changed, but here i want to trace the object which was actually 
> changed i mean to say that the id is for a object not for the objects i 
> created within it. SO now if i want to trace which specific object was 
> modified within that object id .....how do i acheive that?? I see the 
> method getLabel() but it uses invid as a parameter ..and i am still 
> searching how to get invid for the specific object,i changed......Pls 

How can you be sure that only one object changed?

See, in Ganymede, the builds and the object editing transactions are
asynchronous.. that means you might have several distinct transactions
between each run of your Ganymede Builder Task, depending on how long
it takes to do an external build and on how quickly your users are
committing transactions.

Ganymede is designed around the notion that the GanymedeBuilderTasks
will perform a _complete_ build of all object types that have seen any
changes at all made since the last run of the GanymedeBuilderTask.
That's what baseChanged() is for, to tell you whether there have been
_any_ changes made to objects of that type since the last build.

The idea is that the GanymedeBuilderTask will write out all data, then
let the external builder scripts do whatever is required to integrate
that data into the environment.  The baseChanged() method is just a
way to avoid doing things like a DNS build when all that has changed
is some piece of information relating to NIS, etc.  Since your schema
was designed with all kinds of resource records pointing at each
other, you would really do need to do a complete build of a zone any
time ANY resource record object changes that is part of that domain.

Remember, each object in the database has a ModificationDateField
which records the time that the object was last changed.  If you
wanted to, you could do queries on the database during builderPhase1()
of your GanymedeBuilderTask to find objects that have changed more
recently than the GanymedeBuilderTask's oldLastRunTime.  Again,
though, since you have a whole lot of small discrete objects
representing individual resource records rather than large composite
objects which track a lot of data about each system (as our schema
does), it might not do you much good to try to do that, as you'd have
to try and identify all resource records linked into a given zone and
if _any_ of them had changed since oldLastRunTime you'd need to build
the whole zone anyway.

Keep in mind, the fact that builds in Ganymede are asynchronous means
that you can take a long time to do each external build in
builderPhase2() if you want to, and it won't block other things in
Ganymede.  Your users can resume committing transactions as soon as
all registered GanymedeBuilderTasks have exited their builderPhase1()
methods, so having builderPhase2() take a long time (i.e., having your
external build scripts take a long time) probably won't pose a big
problem as far as your users are concerned.

If you're concerned about unnecessarily rebuilding zones that haven't
changed, the simplest thing to do coding-wise might be to just have
builderPhase1() write out all zone files, and then have your external
build scripts compare each zone file to the last version of the zone
file and if there are no differences, simply not bother pushing that
zone.

I.e., this sort of logic:

1. User makes a change to a DNS object of some sort in Ganymede
2. Your GanymedeBuilderTask's builderPhase1() method writes out all
   information in the Ganymede database to disk and returns.

-- the Ganymede server is now ready for other users to start making more changes
   to the Ganymede database.. any such changes will be processed in a subsequent
   build --

3. Your GanymedeBuilderTask's builderPhase2() method runs external build script
4. Your external build script compares each zone file written out by your
   builderPhase1() method with a saved copy from the last time the
   external build script was run, using something simple like diff.  Any
   zones which have not changed since the last external build are not bothered
   with.
5. Your external build script makes back-up copies of all zones written out
   by builderPhase1() for use in performing comparisons the next time a build
   is issued.
6. Your external build script exits
7. Your GanymedeBuilderTask's builderPhase2() method completes

-- The Ganymede server schedules a new build of your GanymedeBuilderTask if
   users have committed any transactions since the build started, otherwise
   waits until someone does commit a transaction. --

Never forget that the Ganymede server itself is only one part of the Ganymede
system.. the external build scripts are a critical piece of the puzzle, and
there are a number of tasks that are simpler to do in the external scripts than
in the Ganymede server itself.  Don't get hung up about doing extremely fancy
logic in the Ganymede server for things that would be easier to do in the
external build scripts.

> Help
> Thank you
> Gaurav

-------------------------------------------------------------------------------
Jonathan Abbey 				              jonabbey@arlut.utexas.edu
Applied Research Laboratories                 The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX     http://www.arlut.utexas.edu/gash2

----------------------------------------------------------------------------
To make changes to your subscription to the Ganymede Help list, send
mail to majordomo@arlut.utexas.edu.

To unsubcribe, include the line

unsubscribe ganymede-help

in the body of your mail message

Visit the Ganymede web page at http://www.arlut.utexas.edu/gash2

----------------------------------------------------------------------------