Description of problem:
rhnKickstartableTree table contains a column last_modified, which gets
populated by satellite-sync with data from hosted or channel dump. These
values play an important role when creating a time constrained
(aka incremental) channel dump: it determines which kickstartable trees
will fall into the specified date range and which won't.

Satellite 5.3.0 schema defines following trigger:
create or replace trigger
rhn_kstree_mod_trig
before insert or update on rhnKickstartableTree
for each row
begin
     if (:new.last_modified = :old.last_modified) or
        (:new.last_modified is null ) then
             :new.last_modified := sysdate;
     end if;

        :new.modified := sysdate;
end rhn_kstree_mod_trig;
/

When CobblerSyncTask is run (by taskomatic), it modifies existing rows
in rhnKickstartableTree table and causes the last_modified values to be
overwritten by sysdate (current date & time).

Version-Release number of selected component (if applicable):
satellite-schema-5.3.0.23-1.el5sat
spacewalk-schema-0.5.20-23.el5sat
spacewalk-java-0.5.44-69.el5sat

How reproducible:
Always

Steps to Reproduce:
1. Install Satellite 5.3.0, synchronize rhel-5 channel from hosted
2. sqlplus `spacewalk-cfg-get default_db`
3. SQL> select label, to_char(last_modified,'YYYY-MM-DD HH24-MI-SS')
        from rhnKickstartableTree;
4. Wait for CobblerSyncTask to wake up (you'll see log entries in
/var/log/cobbler/cobblerd.log like this:
2010-03-22 12:53:01,302 - api - login attempt; user(taskomatic_user)
2010-03-22 12:53:01,495 - api - authenticate; ['taskomatic_user', True]
2010-03-22 12:53:01,497 - api - login succeeded; user(taskomatic_user)
2010-03-22 12:53:01,668 - api - get_distros; user(?)
2010-03-22 12:53:01,971 - api - get_profiles; user(?)
2010-03-22 12:53:01,983 - api - get_systems; user(?)
5. After you see the task has been executed, connect to your database with
sqlplus
6. SQL> select label, to_char(last_modified,'YYYY-MM-DD HH24-MI-SS')
        from rhnKickstartableTree;
  
Actual results:
The last_modified values will get overwritten with sysdate.

Expected results:
last_modified values will be preserved.

Additional info:
The problem described above defeats the fix from
https://bugzilla.redhat.com/show_bug.cgi?id=246480