I'm surprised the module doesn't count images for each gallery. It's important to have counts in the database for sorting & filtering. For example, I want to hide empty galleries in the public directory.
Runtime counting using GROUP BY is not an good solution because of poor Views 2 support & InnoDB low counting performance.
I'm willing to work on it. Will you accept a patch to Node Gallery with this feature ?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

justintime’s picture

I would, but let's define what would need addressed:

1) views integration. This would actually be easier with the count stored in the db, but we'd have to pull the current implementation out.
2) hook_update_N() implementation to pre-populate the db
3) Define what the count represents - is it the number of Published images, or total images? Currently we do the former by default, but it's user-configurable by editing the sort view.

I don't think it would be too hard, because we already have extrapolated the code for counting into atomic helper functions.

All that being said, I think it may be easier to simply extend the current implementation of node_gallery_views_handler_image_count to be used in sorts and filters. There, we're using drupal's db cache and static caches to store the lists of images, and no matter how fast the db is, you can't outrun a count($array) :)

Thoughts?

crea’s picture

1 and 2 are clear points.
3 can be configurable. Making it configurable shouldn't be hard.
Overall I think I need to inspect the code more closely.

crea’s picture

On choosing between counted published/all: I'm going with both. User will be able to select which one to use by choosing proper field.

crea’s picture

Btw, gallery comment count and image updated date are good candidates for storing in DB. Someone may want to sort by these values, like to show "most commented galleries" and "recently updated galleries" lists.
But converting them into DB columns is out of the scope of this patch :)

crea’s picture

Tricky part is postponing counting for mass operations. It doesn't make sense to count after each image if you are going to upload/update 100 images in a batch. But then, if the operation breaks in the process, we get broken counts.
I think I will update after each image - it shouldn't be that slow to count gallery images. We are not talking about counting all images on the server.

crea’s picture

Do we need node_gallery_views_handler_image_count at all, besides displaying image count in views ? I'm going to remove it. Counting will not need special handlers - default ones from Views will do.

crea’s picture

Status: Needs review » Active

I've decided not to use cached list of gallery nids for several reasons:
1) It's not useful in mass operations when cache is being cleared many times
2) we still need to count nodes in the database directly, when cache is missing
3) We don't have a function to count all (including unpublished) nodes (using a cached list), and I wanted to implement consistent approach. Implementing the function seems to be not very useful.
4) Counting single gallery images should be very fast operation even in InnoDB, assuming using of indexes. We also enjoy DB query cache in many cases, such as mass operations.
5) We can always implement some caching later, but we shouldn't resort to premature optimizations. I assume counting in the database has no penalty because it happens only during updates.

crea’s picture

Status: Active » Needs review
FileSize
10.42 KB

Patch attached

justintime’s picture

Status: Active » Needs work

This looks really solid -- nice work. Just a few points:

+++ b/node_gallery.incundefined
@@ -686,6 +686,31 @@ function node_gallery_get_image_count($gid, $reset = FALSE) {
+  $all = (int) db_result(db_query("SELECT COUNT(*) FROM {node_gallery_images} WHERE gid = %d", $gid));

We should do one query here that gets the nid and the status. Then we can iterate over the results incrementing both counters if it's published, but only $all if it's not.

This won't save a lot on one image, but if I update a large set of images, it could save a lot of queries.

+++ b/node_gallery.installundefined
@@ -860,3 +880,72 @@ function node_gallery_update_6304() {
+  $fields = array(

To save changing schema definitions in two spots later, you should call node_gallery_schema() and pull your field definitions from that.

+++ b/node_gallery.installundefined
@@ -860,3 +880,72 @@ function node_gallery_update_6304() {
+  $indexes = array(

Same here - use node_gallery_schema to get your index definitions.

+++ b/node_gallery.installundefined
@@ -860,3 +880,72 @@ function node_gallery_update_6304() {
+  $res = db_query("SELECT gid, count(*) AS c FROM {node_gallery_images} GROUP BY gid");

Same here as above, let's query once, and iterate over the results and increment the counters. Some users have a lot of galleries on crappy webhosts with slow MySQL db's.

+++ b/views2inc/node_gallery.views.incundefined
@@ -105,13 +105,46 @@ function node_gallery_views_data() {
+    'help' => t('The number of images in the gallery, including unpublished.'),

t('The total number of published and unpublished images in the gallery.')

If we could get these fixes in, I'd love for one community member to test this before I commit, but if everyone's busy I'll see if I can get some time. I'm headed out of town for some family time and won't be back until middle of the week next week.

crea’s picture

Using hook_schema in hook_update_N is bad practice. Also, why waste time on removing lines if I already spent it on writing them ?

justintime’s picture

Also, why waste time on removing lines if I already spent it on writing them ?
Umm, because of DRY? However, thanks for the reference, I didn't know that about hook_schema().

Also, if you could run that patch through coder module, you'll see a bunch of whitespace issues. If you can fix those now it'll save me time fixing them before the 3.0 release.

crea’s picture

Status: Needs work » Needs review
FileSize
10.56 KB

Funny thing is that reference doc is perfect example of why someone shouldn't use DRY to the extreme :)

On counting using single query: I rewrote it to count in DB. I think it's much better..
I've also fixed whitespace issues and changed that field description string as you asked.

crea’s picture

Since you released 3.0 without this feature, I can move it into a separate module.

justintime’s picture

Status: Needs review » Needs work

That's up to you, but I think this does belong in "core" NG. I just didn't want to drop in an untested feature right at the 3.0 release, and I didn't have the time to test it myself. With 3.0 out of the way, if you can re-roll the patch against HEAD (doesn't apply cleanly anymore), I'll commit it in so we can get some testers that way.

dddave’s picture

I agree that this should go into core. Good milestone for the next dev cicle for the D6 branch.

crea’s picture

Status: Needs work » Needs review
FileSize
10.59 KB
justintime’s picture

Status: Needs review » Fixed

Committed to 6.x-3.x-dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.