oh and by the way setting a default on the field wont fix it either
because it actually explicitly inserting a blank entry
On Fri, Mar 23, 2012 at 9:48 AM, Paul Robert Marino <prmari...@gmail.com> wrote:
> Well I somewhat agree this is a work around and after the bug in the
> insert to the server history log is fixed the constraint should be re
> added via the following sql statement by any one who has implemented
> the work around
> "
> ALTER TABLE ADD CONSTRAINT vn_rhnserverhistory_details CHECK
> (((details)::text <> ''::text));
> "
>
> As for why the trace I included in the ticket does explain it.
> the table contains the history log for changes to the hosts profile.
> during the re registration process it updates the release information
> in the hosts profile, unfortunately there is a bug in the code where
> its only giving a summary and leaving whats suppose to be the full
> description in the history log blank. the only thing this should
> effect is views of the hosts history,
>
> As for the first part
> "
> spaceschema=# select id,channel_arch_id from rhnChannel where
> label='sci-linux-6_2';
> id | channel_arch_id
> -----+-----------------
> 109 | 513
> (1 row)
> spaceschema=# insert into rhnDistChannelMap
> (os,release,channel_arch_id,channel_id) VALUES
> ('sl-release','6.2','513','109');
> "
> is a sound hack. There should be a way to do this from the web
> interface and or the command line but as far as I've been able to
> determine there isn't one currently although there are API calls for
> it,
> I may write a script to do it if there isn't already an established
> method to do it that I've missed.
>
> Although the distchannelmap does not resolve the fact that the base
> channel from the second key is being ignored. if the base channel in
> the second key where being honored then the base_channel_rel_archid
> function in the database wouldn't be getting called in the first place
> to determine the base channel.
>
>
>
>
> as for the
> On Fri, Mar 23, 2012 at 4:16 AM, Michael Mraka <michael.mr...@redhat.com>
> wrote:
>> Paul Robert Marino wrote:
>> % for any one whos interested here is the workaround i found
>> % I had to do several alterations to the database
>> %
>> % "
>> % spaceschema=# select id,channel_arch_id from rhnChannel where label
>> % ='sci-linux-6_2';
>> % id | channel_arch_id
>> % -----+-----------------
>> % 109 | 513
>> % (1 row)
>> % spaceschema=# insert into rhnDistChannelMap
>> % (os,release,channel_arch_id,channel_id) VALUES
>> % ('sl-release','6.2','513','109');
>> % spaceschema=# alter table rhnserverhistory drop constraint
>> % "vn_rhnserverhistory_details";
>> % "
>> %
>> % oh by the way if any one is wondering the reason why im dropping the
>> % constraint is if you don't it just breaks again latter with this error
>>
>> Well, I really wonder why you're dropping it. Do you know what's its
>> purpose? Are you sure about consequences of your change?
>>
>> Be prepared to random unexpected errors in future. Moreover you
>> might not be able to upgrade schema in the future.
>> I strongly discourage anyone from doing such modifications.
>>
>> % because of an on the bug the workaround brought to light.
>> %
>> % "
>> % ERROR: new row for relation "rhnserverhistory" violates check
>> % constraint "vn_rhnserverhistory_details"
>> % STATEMENT:
>> % insert into rhnServerHistory
>> % (id,
>> % server_id,
>> % summary,
>> % details)
>> % values
>> % (sequence_nextval('rhn_event_id_seq'),
>> % 1000010018,
>> % E'Updated system release from 6.2 to 6.2',
>> % E'')
>> % "
>>
>> Regards,
>>
>> --
>> Michael Mráka
>> 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
