A possible change for ICAT 4.3

8 views
Skip to first unread message

Steve Fisher

unread,
Aug 21, 2012, 10:58:07 AM8/21/12
to icat-de...@googlegroups.com
While writing tests for the ICAT notification for release 4.2 - which is almost ready - I noticed some usability issues:

To request that the primary key of the entity is stored in the message you request "entityId" but pick it up as "pk". As there is also the field entityName I propose to add an extra field entityId to the message with the same value so that "pk" can be removed in the future.

The message does not include the access type "CRU or D" - this will require one more field in the database table to control its selection.

The support for Notifications for search operations is rather poor - only simple entity names are acceptable. To do a better job would require yet one more field in the database holding a fragment of JPQL. It is not efficient to evaluate each returned entity against the notification requests as this would produce a lot of extra queries - which is why I don't do it currently. What could be done however is to combine the authorization rule with the selection query and then add each notification request in turn - returning, for each request, a count which if non-zero would indicate that the message should be constructed and sent. This would require that a very small number of quite complex queries would need to be formulated. To evaluate the utility of this requires some ideas on how people would actually like to use notifications.

Steve


tom.g...@stfc.ac.uk

unread,
Aug 21, 2012, 12:27:15 PM8/21/12
to icat-de...@googlegroups.com

Hi Steve,

 

I’ve not used the notifications, so have no meaningful comments on the specifics (other than I personally do not need to ‘pk’ to be deprecated first– from my point of view you can just drop it)

 

I can tell you where I see requirements that will probably be satisfied using notifications:

 

1)      Who is accessing my data? – alerting a PI to a download of their data (e.g. their IP they have chosen to upload)

2)      Tracking usage of the catalogue, to answer questions like: “how often does anyone access data over 5 years old?” , “what are the common search terms” , or simply “how much data has been accessed using ICAT on the last 12 months”

 

Best Regards,

Tom

Steve Fisher

unread,
Aug 21, 2012, 12:37:34 PM8/21/12
to icat-de...@googlegroups.com
On 21 August 2012 17:27, <tom.g...@stfc.ac.uk> wrote:
> Hi Steve,
>
>
>
> I’ve not used the notifications, so have no meaningful comments on the
> specifics (other than I personally do not need to ‘pk’ to be deprecated
> first– from my point of view you can just drop it)

Does anybody object to changing "pk" to "entityId" now - for 4.2?

Steve
> --
> http://groups.google.com/group/icat-developers
Reply all
Reply to author
Forward
0 new messages