Description of problem: When investigating duplicate output in bug 252165, we came to conclusion that: - we need to (outer) join rhnChannel with rhnChannelCloned to make hibernate happy; - but the join should be via c.id = c_1_.id, not c.id = c_1_.original_id. I grepped eng/java/code/src/com/redhat/rhn/domain/channel/Channel.hbm.xml and found three more occurencies of outer join with .original_id: <sql-query name="Channel.findByIdAndUserId"> <![CDATA[SELECT {c.*} FROM rhnChannel {c}, rhnChannelCloned c_1_ WHERE c.id = :cid AND c.id = c_1_.original_id (+) AND rhn_channel.user_role_check(c.id, :userId, 'subscribe') = 1]]> <return alias="c" class="com.redhat.rhn.domain.channel.Channel" /> </sql-query> <sql-query name="Channel.findByLabelAndUserId"> <![CDATA[SELECT {c.*} FROM rhnChannel {c}, rhnChannelCloned c_1_ WHERE c.label = :label AND c.id = c_1_.original_id (+) AND rhn_channel.user_role_check(c.id, :userId, 'subscribe') = 1]]> <return alias="c" class="com.redhat.rhn.domain.channel.Channel" /> </sql-query> <sql-query name="Channel.findBaseChannel"> <![CDATA[SELECT {c.*} FROM rhnChannel {c}, rhnChannelCloned c_1_, rhnServerChannel sc WHERE sc.server_id = :sid AND sc.channel_id = c.id AND c.id = c_1_.original_id (+) AND c.parent_channel IS NULL]]> <return alias="c" class="com.redhat.rhn.domain.channel.Channel" /> </sql-query> That might not be correct. Version-Release number of selected component (if applicable): 5.1.0. How reproducible: I just looked at the code. Steps to Reproduce: 1. I don't really have steps here. I assume that somewhere, these queries might cause problems and duplicate output. 2. Find those places. Actual results: Duplicate output. Expected results: No duplicate output and profit. Additional info: This is mainly a placeholder for investigating whether those joins with .original_id are legit or not.
These SQL queries are used only in eng/java/code/src/com/redhat/rhn/domain/channel/ChannelFactory.java, via singleton.lookupObjectByNamedQuery calls, which leads to HibernateFactory's lookupObjectByNamedQuery, which does Query query = session.getNamedQuery(qryName) .setCacheable(cacheable); bindParameters(query, qryParams); retval = query.uniqueResult(); I assume that uniqueResult protects us from the duplicates, so fixing that SQL (for the sake) of fixing it should not have any ill effects. And could probably be punted off to 5.2.0.
This was fixed prior to opening up Spacewalk. Here is the initial Spacewalk commit: http://git.fedoraproject.org/git/?p=spacewalk.git;a=blob;f=java/code/src/com/redhat/rhn/domain/channel/Channel.hbm.xml;hb=c43c7764d22ca8a78fd6f446b0892b6dec5e78a8
TEST PLAN ---------- This is a code inspection bug, not a qa-able bug. Please download the spacewalk-java*.src.rpm untar the code and find Channel.hbm.xml. Verify that the above matches.
No more occurrences of c.id = c_1_.original_id found in java/code/src/com/redhat/rhn/domain/channel/Channel.hbm.xml Stage validated -> RELEASE_PENDING
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html