Hello,
while diffing schema contents of Spacewalk which was installed and
started and Spacewalk which was never started (actually, just an old
database schema upgraded to latest version), I came across the
following inconsistence:
select LABEL from RHNDAEMONSTATE order by LABEL
< channel_repodata
< clean_current_alerts
< compare_config_files
< daily_summary
< errata_cache
< errata_engine
< errata_queue
< kickstart_session_check
< last_task_completed
< package_cleanup
< repo_sync
< sandbox_cleanup
< satcert_check
< session_cleanup
< summary_populator
< sync_from_cobbler
< synch_probe_state
While the schema which never had Spacewalk (and most probably,
taskomatic) running only has four records there:
entitlement_run_me
email_engine
payloader_engine
pushed_users
Which also matches the content of
schema/spacewalk/common/data/rhnDaemonState.sql
which populates the table with four records. So the table is
considered to be a "register" or "lookup table", having some specific
list of records from installation time, and then we put more data
there during runtime.
What I don't like here is the fact that we go into some trouble
populating the table with four records (and I believe that the
intention was that whatever processes are using that table would only
update the last_poll column for existing records), and then the
application logic adds 17 more records there. For example, I've found
summary_populator in
java/code/src/com/redhat/rhn/taskomatic/task/SummaryPopulation.java
Therefore I believe it's the application code which inserts new
records.
I believe that we should either populate the schema with the full
list of labels that we are going to need, and never insert just update
in the application code; or we should not populate anything (and I
will remove this table from the list of tables that we verify the
schema for). Or maybe the code cannot be prevented from doing insert
to the table RHNDAEMONSTATE (maybe it does delete + insert), in which
case we probably want different table holding the list of allowed
labels and having RHNDAEMONSTATE.LABEL a foreign key to that table, so
that the application code does not insert completely random labels.
Thoughts?
--
Jan Pazdziora
Principal Software Engineer, Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
