create logical albums by selecting multiple photos by ticking checkboxes

[kagahd]

As an PiGallery2 administrator I'd like to be able to select multiple photos in order to create a virtual album of them that can be shared by an URL.

This feature request is related to #38 and #45. However, unlike #38, tags don't need to be written back to photos since this information is ephemeral. Instead, the identifiers of photos that have been selected to make up a virtual album should be stored in PiGallery's database. When the URL to the virtual album expires, the database can remove these photo identifiers.

Unlike #45 , a virtual album is not based on an advanced search. Instead, photos should be selectable by ticking checkboxes on the photos to select them for the virtual album.
The idea is inspired from the app "Photo Station" of the Synology DSM software (see screenshot below or try out the demo).

[bpatrik]

This FR is totally reasonable, I was also thinking if implementing #45 makes still sense.

I kinda came to the conclusion that it does and want to that first (and create place for normal albums).

There is an other blocker on it, namely I consider the DB as cache that I delete from time-to-time. I guess you would not want to recreate your albums after a update or if gallery indexing goes wrong.
So making the DB more reliable is needed to this work properly. There is some DB improvement initiative here #299

Blocked on:

• [Suggestion ] Create a list of tags to create logical albums #45
• Improve SQL performance #299 (soft block)

[kagahd]

@bpatrik , I also think that #45 still makes sense. It's just another use case although both are related.

I guess you would not want to recreate your albums after a update or if gallery indexing goes wrong.

Sure, losing logical albums when the DB needs to be recreated would be fatal. However, to solve this issue, PiGallery2 could make a backup of the logical album table and restore it after the DB has been recreated. It only requires that photo identifiers are deterministic and as such are immutable. Are they?

I understand your wish to improve SQL performance, especially if you found already one of the biggest performance bottlenecks, TypeORM, and an alternative for it, mikro-orm. However, as the benchmark shows, even if mikro-orm outperformans TypeORM, the gain for find queries is far less impressive compared to the other operations insert, update and remove.

Of course, nobody would complain if adding or removing photos or re-indexing them were faster but, as for me, I'm satisfied with the actual speed already.
Secondly, these operations are not as common as searching for photos, so I don't really care if indexing of all photos takes 5 or 20 hours, whereas the most time consuming part is probably the conversion of photos and not the SQL part done by TypeORM.
Investing much time to replace TypeORM by mikro-orm in order to find photos just a few seconds faster for complex queries is not worth in my opinion.
Thus, as for me, #299 should not be a blocker.

[bpatrik]

1. DB consistency

• Schema updates
  I had multiple issues with TypeORM around db schema updates, so I ended up keeping track of the entity version manually and resetting the DB if that number changes.

  pigallery2/src/common/DataStructureVersion.ts

  Line 1 in e5cd8b6

  export const DataStructureVersion = 21;

That need to be fixed to have reliable DB.

• Inconsistent Gallery states

Earlier I made a lot of effort to make sure that the disk Gallery state matches the DB gallery state. There are quiet some test also for race conditions too. Even after all the efforts, I still encounter DB inconsistencies (eg.: #285) from what the app cannot recover.

2. SQL performance

• performance

Indeed mikro-orm only performs better for insert,update,delete. I was tricked by the all column, assuming that would be a select *, but that it is only the sum of the times.

You are right inserting photos should not matter. With #299 I mainly want to improve the select queries. #277 will have a 2-4x improvement on indexing, that should be enough for now.

#299 wants to improve the selects, not the inserts. According to my experiences, there is some inefficiency in getting data to nodejs from sqlite. Not sure if that is TypeORM or the sqlite adapter itself.

• Improve SQL performance #299 blocker

True #299 is not really a blocker here. What I mean gallery inconsistency should be improved and #299 will be a good opportunity to tidy that up too. (This is what I wanted to hint under "soft blocker")

3. Album implementation

I was thinking sofar in virtual directories that appears in the directory structure. But I find that an odd representation. So I will probably add albums and "virtual directories" (or saved searches) to separate tab.

What do you think?

Disclaimer:
Also please keep in mind I have about 40-80 hours / year on this project. I'm purely building it for my own entertainment and sharing it on github, so others can use it too. In that 40-80 hours, I focus (mainly) on features that I need: #292

[kagahd]

I was thinking sofar in virtual directories that appears in the directory structure. But I find that an odd representation.

True. I'd find it odd too.

So I will probably add albums and "virtual directories" (or saved searches) to separate tab.

@bpatrik, would this mean that everybody who is visiting the gallery could see and click these tabs? I'd prefer that only PiGallery2 administrators see these tabs and are able to share the underlying URL(s). Users who receive this URL would see only the corresponding virtual album, nothing more.
Finally, for my understanding, the goal of virtual albums is to combine different images from a pool of photos into different albums for different user groups.

Disclaimer:
Also please keep in mind I have about 40-80 hours / year on this project.

I'm impressed how much you achieved already! I certainly invested already at least 40 hours into PiGallery2 only since I discovered it a few weeks ago but my contribution is still very limited. I try to get into the code but it's quite difficult for a TypesScript/Angular2/Nodejs newbie like me...

[bpatrik]

Yes, admin would be able to create albums and all users would be able to see them.

Unfortunately sharing is not supported for search currently (and the same would apply for albums too)

There are some discussion about these in #81, #188, #129