Hello,
Does anyone know of any technical reason why the CatalogPostModifyEvent does not store the before/after state of the CatalogInfo object (similar to the CatalogModifyEvent)?
I have run into a situation where such state would be helpful, and was looking into seeing if this was something that I could add.
Torben
Hi Torben,
I don’t know if there is a reason, but I can relate with your situation. I had to deal with it, by storing the changed values
in a thread local in the pre event to use them later in the post modify event, and it’s… well… ugly :-p
Cheers
Andrea
On Thu, Feb 9, 2017 at 2:19 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Hello,
Does anyone know of any technical reason why the CatalogPostModifyEvent does not store the before/after state of the CatalogInfo object (similar to the CatalogModifyEvent)?
I have run into a situation where such state would be helpful, and was looking into seeing if this was something that I could add.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
I decided to try out what would be involved in adding this functionality.
It looks to be a relatively safe change, as all important API changes are to internal catalog methods.
PR here, open for discussion: https://github.com/geoserver/geoserver/pull/2101
Torben
On Thu, Feb 9, 2017 at 1:41 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Torben,
I don’t know if there is a reason, but I can relate with your situation. I had to deal with it, by storing the changed values
in a thread local in the pre event to use them later in the post modify event, and it’s… well… ugly :-pCheers
Andrea
On Thu, Feb 9, 2017 at 2:19 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Hello,
Does anyone know of any technical reason why the CatalogPostModifyEvent does not store the before/after state of the CatalogInfo object (similar to the CatalogModifyEvent)?
I have run into a situation where such state would be helpful, and was looking into seeing if this was something that I could add.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Seems sensible. I don’t know enough about that area of the code to comment in depth but it seems like a sensible change on a high level.
On Thu, Feb 9, 2017 at 1:41 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Torben,
I don’t know if there is a reason, but I can relate with your situation. I had to deal with it, by storing the changed values
in a thread local in the pre event to use them later in the post modify event, and it’s… well… ugly :-pCheers
Andrea
On Thu, Feb 9, 2017 at 2:19 AM, Torben Barsballe <tbarsballe@anonymised.com839…> wrote:
Hello,
Does anyone know of any technical reason why the CatalogPostModifyEvent does not store the before/after state of the CatalogInfo object (similar to the CatalogModifyEvent)?
I have run into a situation where such state would be helpful, and was looking into seeing if this was something that I could add.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
That sounds terrible Andrea / Torbien.
The only technical reason I could think of if the before state contains references to stores/resources/styles/layer that no longer exist after a delete change. Or are no longer “valid” after a post modify event. I would hate for the event to keep conflicting objects “live” at the same time (say a before and after DataStoreInfo connection parameters which are no longer valid).
On 9 February 2017 at 01:41, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Torben,
I don’t know if there is a reason, but I can relate with your situation. I had to deal with it, by storing the changed values
in a thread local in the pre event to use them later in the post modify event, and it’s… well… ugly :-pCheers
Andrea
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.com.366…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Jody Garnett
On Thu, Feb 9, 2017 at 2:19 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Hello,
Does anyone know of any technical reason why the CatalogPostModifyEvent does not store the before/after state of the CatalogInfo object (similar to the CatalogModifyEvent)?
I have run into a situation where such state would be helpful, and was looking into seeing if this was something that I could add.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
Jody:
Looking at the current implementation, the Modify event stores the object before the change, and the PostModify event stores the object after the change.
In addition, the Modify event stores a list of properties that have changed.
The extent of suggestion is to also store this list of properties on the PostModify event - no conflicting objects would be involved.
Torben
On Thu, Feb 9, 2017 at 12:07 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
That sounds terrible Andrea / Torbien.
The only technical reason I could think of if the before state contains references to stores/resources/styles/layer that no longer exist after a delete change. Or are no longer “valid” after a post modify event. I would hate for the event to keep conflicting objects “live” at the same time (say a before and after DataStoreInfo connection parameters which are no longer valid).
–
Jody Garnett
On 9 February 2017 at 01:41, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi Torben,
I don’t know if there is a reason, but I can relate with your situation. I had to deal with it, by storing the changed values
in a thread local in the pre event to use them later in the post modify event, and it’s… well… ugly :-pCheers
Andrea
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Thu, Feb 9, 2017 at 2:19 AM, Torben Barsballe <tbarsballe@anonymised.com> wrote:
Hello,
Does anyone know of any technical reason why the CatalogPostModifyEvent does not store the before/after state of the CatalogInfo object (similar to the CatalogModifyEvent)?
I have run into a situation where such state would be helpful, and was looking into seeing if this was something that I could add.
Torben
Check out the vibrant tech community on one of the world’s most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.