Re: [Spacewalk-devel] New records get born in RHNDAEMONSTATE
On 01/26/2011 08:51 AM, Jan Pazdziora wrote: On Tue, Jun 15, 2010 at 11:44:55AM -0400, Tomas Lestach wrote: Right, this approach is really not the best one. As this is a part of the taskomatic, I'll investigate it more in detail. I'd touch the code anyway. Not sure if somebody makes use out of the rhnDaemonState table content, but if not (what I suppose), I'd remove the table and the appropriate code. Tomáš, I've noticed that you've dropped the table for 1.3. However, doing git grep -i rhnDaemonState still shows it mentioned in the comments in multiple java/code/src/com/redhat/rhn/taskomatic/task/*.java files. Frankly, I'm a bit unsure that the comment refers to -- the whole class, the DISPLAY_NAME string, the getLogger ... Could you please look at it and clean it up or something? Done. Thanks for letting me know, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat Thank you, ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
Re: [Spacewalk-devel] New records get born in RHNDAEMONSTATE
On Tue, Jun 15, 2010 at 11:44:55AM -0400, Tomas Lestach wrote: Right, this approach is really not the best one. As this is a part of the taskomatic, I'll investigate it more in detail. I'd touch the code anyway. Not sure if somebody makes use out of the rhnDaemonState table content, but if not (what I suppose), I'd remove the table and the appropriate code. Tomáš, I've noticed that you've dropped the table for 1.3. However, doing git grep -i rhnDaemonState still shows it mentioned in the comments in multiple java/code/src/com/redhat/rhn/taskomatic/task/*.java files. Frankly, I'm a bit unsure that the comment refers to -- the whole class, the DISPLAY_NAME string, the getLogger ... Could you please look at it and clean it up or something? Thank you, -- 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
[Spacewalk-devel] New records get born in RHNDAEMONSTATE
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
Re: [Spacewalk-devel] New records get born in RHNDAEMONSTATE
- Jan Pazdziora jpazdzi...@redhat.com wrote: 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? Right, this approach is really not the best one. As this is a part of the taskomatic, I'll investigate it more in detail. I'd touch the code anyway. Not sure if somebody makes use out of the rhnDaemonState table content, but if not (what I suppose), I'd remove the table and the appropriate code. Regards, Tomas -- Tomas Lestach RHN Satellite Engineering, Red Hat -- 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 ___ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
