One-to-many outer join in MView, is possible?

Question

Re: 10g R2
Is it simply not possible to have fast refresh on outer joins that are 1-to-many relations? I have in this script a unique key addition to "fix" it, but it restricts something that I don't want restricted. If indeed this is how it should work, are there any strategies for improving performance for queries on this type of thing? The "fact_table" in this example is actually another materialized view with simple inner joins, so that works perfectly, but I was trying to improve query performance in this case too.
Run the script w/ dbms output...all self contained within the schema.
drop materialized view log on fact_Table;
drop materialized view log on outer_detail;
drop materialized view mview_test;
drop table outer_detail cascade constraints;
drop table fact_Table cascade constraints;
create table fact_table (myid number primary key, fact_attrib varchar2(10));
create table outer_detail (myid number primary key, outer_attrib varchar2(19), fact_table_id number, constraint fk_outer_to_Fact foreign key (fact_table_id) references fact_table(myid));
CREATE MATERIALIZED VIEW LOG ON fact_table WITH ROWID;
CREATE MATERIALIZED VIEW LOG ON outer_detail WITH ROWID;
declare
    v_capabilities sys.ExplainMVArrayType ;
begin
    dbms_mview.explain_mview('SELECT ft.rowid "ftrid", ' ||
       'od.rowid "odrid", ' ||
       'ft.myid fact_id, ' ||
       'od.myid outer_id, ' ||
       'ft.fact_attrib, ' ||
       'od.outer_attrib ' ||
  'FROM fact_table ft, outer_detail od ' ||
'WHERE ft.myid = od.fact_table_id (+)', v_capabilities);
        dbms_output.put_line('ATTEMPT 1:');
        dbms_output.put_line('==============================================');
    for v_capability in (select capability_name, possible, related_text, msgtxt from table (v_capabilities))
    loop
        dbms_output.put_line('==============================================');
        dbms_output.put_line('==============================================');
        dbms_output.put_line(v_capability.capability_name);
        dbms_output.put_line(v_capability.possible);
        dbms_output.put_line(v_capability.related_text);
        dbms_output.put_line(v_capability.msgtxt);
    end loop;
end;
/*CREATE MATERIALIZED VIEW mview_test
PARALLEL BUILD IMMEDIATE
REFRESH FAST ON COMMIT WITH ROWID
AS
SELECT ft.rowid "ftrid",
       od.rowid "odrid",
       ft.myid fact_id,
       od.myid outer_id,
       ft.fact_attrib,
       od.outer_attrib
  FROM fact_table ft, outer_detail od
WHERE ft.myid = od.fact_table_id (+);
-- I'd like it to run without this constraint, is it not possible?
alter table outer_detail add constraint unk_outer_detail unique (fact_table_id);
declare
    v_capabilities sys.ExplainMVArrayType ;
begin
    dbms_mview.explain_mview('SELECT ft.rowid "ftrid", ' ||
       'od.rowid "odrid", ' ||
       'ft.myid fact_id, ' ||
       'od.myid outer_id, ' ||
       'ft.fact_attrib, ' ||
       'od.outer_attrib ' ||
  'FROM fact_table ft, outer_detail od ' ||
'WHERE ft.myid = od.fact_table_id (+)', v_capabilities);
        dbms_output.put_line('');
        dbms_output.put_line('');
        dbms_output.put_line('');
        dbms_output.put_line('ATTEMPT 2:');
        dbms_output.put_line('==============================================');
    for v_capability in (select capability_name, possible, related_text, msgtxt from table (v_capabilities))
    loop
        dbms_output.put_line('==============================================');
        dbms_output.put_line('==============================================');
        dbms_output.put_line(v_capability.capability_name);
        dbms_output.put_line(v_capability.possible);
        dbms_output.put_line(v_capability.related_text);
        dbms_output.put_line(v_capability.msgtxt);
    end loop;
end;
/Edited by: ORA-01435 on Sep 30, 2009 12:54 PM

Answer 1

That's what I thought too. As far as I'm concerned, this is perfectly acceptable. Of course I'm in 10g R2, but:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#sthref534
I keep re-reading the rules, trying to see why it thinks I'm violating one of them. Might have to meta-link this one.
Just ran this on a different box, ran fine. Seem to have configuration issues between the boxes.
Edit: Just determined that the boxes that this doesn't work on have Oracle parameters for compatibility set to 10.1.0.2.0, I'll change them and check if it modifies behavior
Edited by: ORA-01435 on Oct 1, 2009 7:44 AM