Random order by for Oracle

Update status.

I fear noone can test this, so reviewing the code is hard. Does views in general works with oracle.

Please don't shout in issue titles.

Drupal core includes no built in support for Oracle.

My feeling is that whatever provides oracle support and drivers should use hook_views_data_alter() to create its own handlers. This will be much better for Oracle since the people responsible for the driver will have more knowledge and ability to react to problems.

Nor views 3.x or views 2.x uses dbtng, only views 3.x for drupal7.

Orcacle uses dbtng

I can surely do that but looks like a lot more code to maintain...

Perhaps this is not what you intended, but "There's a lot of code to maintain. You do it, I don't want to" does not sway my thinking.

Views' policy is quite particular about its support for contrib. It is designed to be pluggable and overridable and there are a few exceptions to that but in general, these overrides can be done by the module. As a result, it is very rare that I'll accept patches specific to a module, which this is.

So yes, making a subclass inheriting the random sort handler for Oracle specific behavior might require 'maintaining' that code (though history suggests it changes very very rarely) so there isn't really any more maintenance work for you than there is for me. And what I mean is that, I don't run Oracle, I don't have Oracle, so I can't test Oracle patches. I can't respond to problems people have with the Oracle implementation, and I don't want to respond to problems people have with the Oracle implementation. That needs to happen by the people who are writing and maintaining the Oracle implementation.

Also, on closer inspection, the actual code to maintain will be:

1) A subclass of the random sort handler specific to oracle that overrides the formula used in the query() method. Perhaps this would be less code if the formula used were moved to a constructor or something.
2) The appropriate hook_views_handlers() code to declare the handler
3) The appropriate hook_views_data_alter() code to place this handler in place of the original.

It doesn't have to care what the formula for mysql is or changes to because Drupal 6 does not support multiple db types in the same install. So it sticks its own formula in for the query -- that's probably 10-15 lines of code, including structure and closing braces, and doxygen comments.

Now, where I'll listen are where you can come up with patches to Views that makes your job easier. If you can find an easy way to do the overrides with a little less code, great! So maybe there's a way to reorganize the handler. More likely, there's going to be something else (date manipulation I'll wager) that needs oracle specific behavior. Perhaps I'll need to provide some kind of hook or something. I'm open to things like that. Those will allow you to do your job more effectively.

He definitive means a extra contrib module. You can definitive add a module in your package and write something into your INSTALL.txt. that you need this module for oracle and views.

Every documentation is in help directory included into views. There are some contrib modules out there, which replaces the handler of something else.
One example is http://drupal.org/project/views_taxonomy_selective_filter

"So, may maybe you can include those pieces of code and i can help maintain it"...

Views is already such big, every thing which is not a "implementation" of drupal core, should be moved out.

I would think that maybe there needs to be an oracle_views module that is packaged with the oracle driver backend, then.

I don't see a total reason for doing this, as you can override the handler already at the moment.

VIews2 is in a only critical bug fixes only state, so this will not going to happen.