Having run across this problem while helping with the LR2Zenphoto plugin, it appears there is a need for an additional field in the image tables. It would help if there was a field (external_id?) that could be set for maintaining a unique id from an external program (such as LR). Right now, the plugin uses name and date/time for identifying the image. This fails when there are virtual copies (which share all of the creation info). However, every entry in the database has a unique image id, so being able to store that would solve the issue of attempting to find matching images when more than one copy exist.

The ID is unique for Zenphoto unless you delete an image. So why an additional one?

In Zenphoto the id is NOT the unique identifer actually, Zenphoot internally for its object model uses the filename and the album name (more exact the album folder tree if in an subalbum) to identify an item.

If you refer to Lightroom the current developer jphilbert of it would be a good address to discuss the plugin's needs. http://philbertphotos.github.io/Zenphoto-Lightroom-Publisher/

I'm working with Joe on this, and he's run into the problem where he's having trouble discerning between virtual copies of an image. LR has an internal id of every entry in it's database, and the reason to have "another one" is not that it's zenphoto's issue, but a place to store the unique id of the remote application (LR in this case) to make it virtually impossible to mis-identify an image. Right now, plugins have to guess when a file name/date/whatever match more than one image in the original exporting application. The ID in zenphoto is zenphoto's, and most likely used for internal use. This would give a place to store an external id, for the original applications use. Two different things, but think of it as a way to index two database entries. :}

Ok, didn't know that.. You will understand that we won't add database fields because "one 3rd party plugin" might need them.

If you need extra database fields you should try to use the `plugin_storage` table for that. Use Zenphoto's id to link that to the `images` table.

PS: It would really help readability if you would use some paragraphs sometimes..:-)

I had figured that an external identifier might be needed by more than one application, so was a potential addition to the database.

The plugin_storage isn't really that useful for this need; it would require the plugin to maintain a separate data structure (and all of the managing routines). This seems like a really high overhead for something that could prove beneficial to many other plugins, or could if they knew one was there. ;}

As a programmer, it also feels to me like something that got left out, because nobody thought integrating with external programs was important. That may not be the reason, but when you have the abilities to install plugins that potentially automate from other sources, then some additions for ease of integration should be considered. A way to uniquely identify an image is such a one...

Anyway, it would be a simple and useful expansion to the whole idea of automating other sources, and does help immensely with the problem of cross-indexing images between zenphoto and external applications. Thus the request...

Cheers!

Well, the need never appeared in several years of Zenphoto...:-)

The plugin_storage table actually was exactly made for custom needs on the table (a concept from WP btw). Several plugins use them already (RSS hitcounter, downloadlist). For that table there are even no object methods since you can use it in too many possible ways.

Anyway, feel free to open a ticket on the Github issue tracker. The "chief" will decide about it then.

Just because the need hadn't been asked for before doesn't mean it wasn't there! Just that nobody asked loud enough.. :}

I'm looking over the requirements for using the plugin storage; but it looks like then he'd need to do an sql query (since the index can not be the same as the zenphoto id if more than one plugin is using it, so simple way is out)? Or am I just remembering it wrong?

Didn't you tell him not to do sql queries directly? :}

I'll probably add it to the bug tracker, and see what dust I can shake off.. :}

Cheers!

Just because the need hadn't been asked for before doesn't mean it wasn't there! Just that nobody asked loud enough.. :}

Not our fault if no ones says something..:-)

To the plugin storage and your question with several plugins I did answer on your ticket how to do it.

Yes, generally you should not use mysl for Zenphoto items. Plugin storage has no fixed usage as with these on that table. You can use the fields it provides creatively for anything you desire and make up so it is up to you. Thus there are no object methods for it. Which does not mean that your plugin could not have some for it if needed or even extending the image class via the plugin (like the video/textobject classes do).

Thanks jasonized I already started with the plugin_storage route a few days ago and already added the code in the plugin RPC. Virtual Copies is a pain but that the only "easy" solution.

I will also use it to store things like ablum password since "getpass" give me back a hash and can be bit useless on the lightroom end

SO it will be plugin_storage-Album ID and an array or JSON of custom data for that album ...albumpassowrd, virtual copy ID etc...

@jphilbert: If plugin_storage fits your purpose, good. Otherwise join the discussion on the ticket:
https://github.com/zenphoto/zenphoto/issues/389

Just an observation:

I had figured that an external identifier might be needed by more than one application, so was a potential addition to the database.

is kind of open ended--each use would require a new unique field in the image table. Not really a viable situation. This kind of issue calls for mapping tables which is what was suggested to you.