Very true. For one, I wish that they would find a solution to those MDRT-tables. I can understand that they have to be there, but couldn't they be hidden by default or something? It's cluttering a schema.
Oracle started with the whole spatial storage in the late nineties - you'd think that by now geometry data would have become mainstream, including the indexing of it.On the other hand, I still think Oracle's solution is the most elegant that exists out there - and I've been around this business since the early nineties, when using a CAD to maintain your drawings was considered flashy
According to Oracle support - spatial indexes, at least in terms of materialized views, are not recognized as a known Oracle index type. Therefore they are handled just like any user-defined domain index. In this case, if the non-atomic refresh recognizes that there is a domain index on the MV, it will instead refresh it atomic - no matter what you specify.
In other words, Oracle won't expend any development dollars to make this work correctly. Instead they plan to update the documentation to note this behavior. Not exactly what we like to hear when we pay support on this add-on each year. I was half-expecting the dreaded "fixed in 12c" answer, but this is worse.
Although this issue can be worked around by the user, it is most troublesome when you have parent materialized views that you would normally refresh with the child using DBMS_MVIEW.REFRESH_DEPENDENT. Instead you (the user) will need to write your own code to walk the dependency tree and refresh all the MV's (first dropping the spatial index, refreshing, then re-creating the index), in order. Nor horribly difficult - but again something we as end-users should not need to do. No other Oracle index types are treated this way.
Come on Oracle - get on the stick and make this right.
I can't agree more. I understand why they are there - but I never understand why they show up like any other table. I guess that keeps the code base simpler, since they can be treated like any other generic table.
And yes, I still think their solution is the best out there. However, other competing products are not static and are making steady progress. I'm not sure in a few years time I will be able to say the same thing if development on basic functionality is ignored.
Good! Do they specifically mention Spatial Indexes? Then we finally may see some proper integration of spatial data with alfanumerical data :-)
Let's hope this will be fixed with the next patch, because even though I haven't run into this particular one I do have customers that use MV's extensively, so it's only a matter of time before one of them will suddenly have issues too.