catalog:get/setPropertyForPlugin

[Mark_J_M_Wilson]

Is anybody using the new catalog get and setPropretyForPlugin yet?

The SDK isn't very explicit on how these work - my take is that they allow a plugin to create metadata fields on the catalog (rather than photos) and that you don't have to define the field in advance...

However, I can not seem to get them to work at all.

     local catalog = LrApplication.activeCatalog()

     LrTasks.pcall( function() catalog:withWriteAccessDo( "Set some metadata",

          function()

               catalog:setPropertyForPlugin(_PLUGIN, "fred", "Some stuff")

               catalog:setPropertyForPlugin(_PLUGIN, "john", "Other stuff")

          end)

          local linkIDList = catalog:getPropertyForPlugin(_PLUGIN, "fred")

          local linkNameList = catalog:getPropertyForPlugin(_PLUGIN, "john")

     end)

Anyone any ideas?

Cheers

Mark.

[areohbee]

I'm not sure what symptoms you were having, but I just tried it and this is what happened:

catalog:setPropertyForPlugin - executed without error.

catalog:getPropertyForPlugin - caused an error with trapped message: "Could not copy value between states" - which the same error I get if I pass a "surelynottobefoundname" for the field-name.

Is there a secret?

Rob

[Mark_J_M_Wilson]

That is the same symptoms Rob.  Did you copy and paste my code or use your own?

[areohbee]

Mark,

I used my own code, and I played with it a fair bit - tried "get"-ing in a separate with____Do gate... - I think its broken!

Chet? Mr. Drarvik?? - You didn't quit already did you??? - Too busy to read the forum???? - Policy not to respond?????

Rob

[areohbee]

At the risk of stating the obvious, workaround-wise - If your property does not have to be specific to the catalog, then LrPrefs will do. And now that I think about it, you could always prepend the catalog id and roll your own catalog:set/get methods using prefs. Except I don't see how to obtain a catalog ID, hmmm.. you could use the path, but then if it got moved you'd be hosed. - Another feature request coming...

Rob

[Vladimir_Vinogradsky]

Mark,

I believe you're trying to read items outside of a gate. Try changing your code as follows:

local catalog = LrApplication.activeCatalog()

LrTasks.pcall(
    function()
        catalog:withWriteAccessDo( "Set some metadata",
                                    function()
                                        catalog:setPropertyForPlugin(_PLUGIN, "fred", "Some stuff")
                                        catalog:setPropertyForPlugin(_PLUGIN, "john", "Other stuff")
                                    end)
        catalog:withReadAccessDo( "Read some metadata",
                                    function()
                                        local linkIDList = catalog:getPropertyForPlugin(_PLUGIN, "fred")
                                        local linkNameList = catalog:getPropertyForPlugin(_PLUGIN, "john")
                                    end)
    end
)

Sorry for taking the liberty and re-formatting the code to my liking

PS: Also, keep in mind, you can't write and read inside of the same callback function, you must let the "write" gate to complete and come back, only then you can "read".

[Mark_J_M_Wilson]

Thanks Vladimir.  You are right, my test code had the get calls outside the with_accessdo call - I must have got desperate trying anything

Following your comment of reading and writing in the same callback - if I move the gets to a separate "catalog:withReadAccessDo( function()" I still get the same copy between states error.  However, moving them to a complete new LrTask seems to work - although I haven't tested this completely yet.

Thanks for the help!  I'll post more when I get a chance to test the behaviour a little more.

[Vladimir_Vinogradsky]

Mark,

If you are using two separate asyncronous tasks, chances are, they would be running in parallel. So the first task may still be "writing" when the second task is attempting to "read". Just something to watch out for.

Anyway, let us know what you find in your testing.

[areohbee]

From the best I can tell this function is completely broken.

Has anyone ever gotten it to work???

Rob

[areohbee]

At some point in a Lr3 dot rev, Adobe nearly fixed this function.

@LR3.4.1, It *sometimes* works with private access, and it always(?) works with full write access.

I use a work-around now that just uses reglar lr-prefs-for-plugin and prefixes the catalog path (with illegal key chars removed) to the target property name.

Accomplishes the same thing for my purposes and is faster and more reliable and requires no with-do gate.

Rob

[Guest]

I'm finding this family of functions are very sensitive to timing, and the timing is very different in different interpreters and in different contexts (e.g., when run in your own dialogue vs. one of the SDK callbacks)

As pointed out, we end up being in a number of async tasks often, and I suspect much of my problems end up being routine contention.  Sometimes putting yileds() in silly places seems to help.

Other places, though, these accessors can be hacked on for days and nothing seems to help.