Random Image Block

ok，The next release will add random image block

Thank you, I want this feature too :).

Hey, Views already has a "random" sorting method so I think it would be simpler to expose your fields and logic to the Views module. Then users can make up their own random image blocks that work the way they like. They could use all the other Views logic to make the block as random or structured as they wish. Don't try to invent this from scratch when its already been done!

@ #3

This may be true if views integration is already set up... However, album photos does not use nodes to save images and there is no existing views integration. So, views integration would be more flexible but also *way* more complex to set up than a few lines which select some random rows from the database. Perhabs in a later version....

On-Topic:

The feature was commited but it does use RAND(). This has two problems:

a) RAND() is mysql-specific, for example it is called RANDOM() in pgsql. This can be solved easily... check the database type and use RAND() or RANDOM()... (views does the same, just checked it)

    global $db_type;
    switch ($db_type) {
      case 'mysql':
      case 'mysqli':
        $rand = 'RAND()';
        break;
      case 'pgsql':
        $rand = 'RANDOM()';
        break;
    }

    $result = db_query_range('SELECT fid, ' . $rand . ' AS rand FROM {x_image}  ORDER BY rand',$num);

b) It does not scale well if there are many photos (RAND()-call for every row and then sort it without index). I am however not sure if this is relevant as it is only really problematic if you have many thousand photos. There are some ways to solve this but they have their downsides too.

You really should tap into Views. All the cool modules are doing it... :)

at b)
I'm not sure, but I think it shouldn't sort without index as your selecting the random value. I think it would be without index if you did a ORDER BY RAND(). It might still be inefficient though (would have to check explain). If the table has an auto_increment value you could also just select the max-value (which should hopefully be optimized better) and multiply it with rand(), like

SELECT FLOOR( MAX(fid) * RAND() ) FROM {x_image}

#5

I know, I'm using Views for different things on my sites. Because of that I also know that it wouldn't be so easy to expose the image information to Views as they are not stored as nodes. Albums however is another story as they are nodes with some additonal infos. Again, perhabs in a later version...

#6
I don't know much about mysql internals, but why should it make a difference if one is using "RAND() as rand ... ORDER BY rand" or "ORDER by RAND()". In both cases, mysql has to read every row in the table first and call RAND(), ending up in a temporary table like this:

| fid | RAND() |
| 1 | .23456 |
| 5 | .54676 |

After that, it has to sort this list by the values in the RAND() column for which of course no index exists.

I tested a similiar approach as yours. The first problem is that the id column probably isn't complete...if images were deleted you end up with spaces. This can be solved with reading out the next or previous id. The second problem is that this only works for a single row, because only the starting point is random. I didn't found a good solution for this problem.

Perhaps the scope of inquiry appointed(100, or the recent 1000), the efficiency will be increased.

You are of course right Berdir, I was a bit confused about indices in mysql. I think you could solve it by querying more than one time, but that will be more inefficient in the case of small tables, so it's hard to get perfect scaling.