You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Erik de Hair <e....@pocos.nl> on 2017/01/04 08:32:28 UTC

Prevent command from being persisted

Hi,

We have a view model with following action:

@Action(domainEvent = WbaOrderFinishedEvent.class, publishing = 
Publishing.DISABLED, commandPersistence = CommandPersistence.NOT_PERSISTED)
@Override
public AbstractEndUserAccessSubscription finish(){
     ....
}

The application is still trying to persist the action as a command and 
it complains about the length of the target-column, while it should be 
set to null for view models, isn't it?

INSERT INTO Command 
(arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId) 
VALUES (<''>,<2017-01-04 
09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store value 
"*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4=" 
in column "target" that has maximum length of 2000. Please correct your 
data!

How to fix this?

Thanks,
Erik


Re: Prevent command from being persisted

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Currently there are only two levels... foreground and background.

On Tue, 10 Jan 2017, 10:33 Erik de Hair, <e....@pocos.nl> wrote:

>
> On 01/06/2017 12:38 AM, Dan Haywood wrote:
> > Hi Erik,
> >
> > Looks like an error in BackgroundCommandServiceJdo [1].  It's setting the
> > child command's reference to the parent command, and then the latter gets
> > persisted due to persistence-by-reachability.
> >
> > You can workaround this by creating your own version of
> > BackgroundCommandService2, with @DomainService(menuOrder="50") say so
> that
> > it is picked up first.  Copy the existing class and adjust.
> >
> > Ideally the implementatation needs to find out the ObjectAction
> > corresponding to the parent Command, and check its CommandFacet.  That
> will
> > mean reaching deep into the Apache Isis metamodel, I think ... I don't
> > think there's any formal API for that I'm afraid.
> >
> > Or, you could go for the cheap-n-cheerful approach which is to check for
> > the length of the targetStr of the parent Command, and set the child's
> > parent ref to null if too long.  You could use code similar to that in
> > CommandServiceJdo to do this [2]
> How many levels can a command tree have? If more than 2 it would have to
> check this recursively...
> >
> > Meantime I've raised an issue on the module [3].  PRs happily received if
> > you have the time to fix properly.
> Thanks Dan, will see if/how I can fix this.
> >
> > Thx
> > Dan
> >
> >
> > [1]
> >
> https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/BackgroundCommandServiceJdo.java#L117
> > [2]
> >
> https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/CommandServiceJdo.java#L92
> > [3] https://github.com/isisaddons/isis-module-command/issues/14
> >
> >
> > On Wed, 4 Jan 2017 at 14:18 Erik de Hair <e....@pocos.nl> wrote:
> >
> >> On 01/04/2017 10:14 AM, Erik de Hair wrote:
> >>> So now it seems an action in the registered domainEvent is persisted
> >>> as a command and while debugging I can see the finish()-action is it's
> >>> parent command. Will persisting the action from the domainEvent
> >>> trigger persistence of it's parent also, eventhough it shouldn't be
> >>> persisted? The targetStr-property of the finish()-command is not null.
> >>> Could that be messing things up?
> >>>
> >> It ís messing things up. The subscriber for the WbaOrderFinishedEvent
> >> starts another background-command. If I disable this call everything
> >> works fine. This call really needs to be done in the background so how
> >> can I make this work?
> >>
> >>> On 01/04/2017 09:32 AM, Erik de Hair wrote:
> >>>> Hi,
> >>>>
> >>>> We have a view model with following action:
> >>>>
> >>>> @Action(domainEvent = WbaOrderFinishedEvent.class, publishing =
> >>>> Publishing.DISABLED, commandPersistence =
> >>>> CommandPersistence.NOT_PERSISTED)
> >>>> @Override
> >>>> public AbstractEndUserAccessSubscription finish(){
> >>>>      ....
> >>>> }
> >>>>
> >>>> The application is still trying to persist the action as a command
> >>>> and it complains about the length of the target-column, while it
> >>>> should be set to null for view models, isn't it?
> >>>>
> >>>> INSERT INTO Command
> >>>>
> >>
> (arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId)
> >>>> VALUES (<''>,<2017-01-04
> >>>> 09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store
> >>>> value
> >>>>
> >>
> "*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4="
> >>>> in column "target" that has maximum length of 2000. Please correct
> >>>> your data!
> >>>>
> >>>> How to fix this?
> >>>>
> >>>> Thanks,
> >>>> Erik
> >>>>
> >>>
> >>
> >>
>
>
>

Re: Prevent command from being persisted

Posted by Erik de Hair <e....@pocos.nl>.
On 01/06/2017 12:38 AM, Dan Haywood wrote:
> Hi Erik,
>
> Looks like an error in BackgroundCommandServiceJdo [1].  It's setting the
> child command's reference to the parent command, and then the latter gets
> persisted due to persistence-by-reachability.
>
> You can workaround this by creating your own version of
> BackgroundCommandService2, with @DomainService(menuOrder="50") say so that
> it is picked up first.  Copy the existing class and adjust.
>
> Ideally the implementatation needs to find out the ObjectAction
> corresponding to the parent Command, and check its CommandFacet.  That will
> mean reaching deep into the Apache Isis metamodel, I think ... I don't
> think there's any formal API for that I'm afraid.
>
> Or, you could go for the cheap-n-cheerful approach which is to check for
> the length of the targetStr of the parent Command, and set the child's
> parent ref to null if too long.  You could use code similar to that in
> CommandServiceJdo to do this [2]
How many levels can a command tree have? If more than 2 it would have to 
check this recursively...
>
> Meantime I've raised an issue on the module [3].  PRs happily received if
> you have the time to fix properly.
Thanks Dan, will see if/how I can fix this.
>
> Thx
> Dan
>
>
> [1]
> https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/BackgroundCommandServiceJdo.java#L117
> [2]
> https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/CommandServiceJdo.java#L92
> [3] https://github.com/isisaddons/isis-module-command/issues/14
>
>
> On Wed, 4 Jan 2017 at 14:18 Erik de Hair <e....@pocos.nl> wrote:
>
>> On 01/04/2017 10:14 AM, Erik de Hair wrote:
>>> So now it seems an action in the registered domainEvent is persisted
>>> as a command and while debugging I can see the finish()-action is it's
>>> parent command. Will persisting the action from the domainEvent
>>> trigger persistence of it's parent also, eventhough it shouldn't be
>>> persisted? The targetStr-property of the finish()-command is not null.
>>> Could that be messing things up?
>>>
>> It ís messing things up. The subscriber for the WbaOrderFinishedEvent
>> starts another background-command. If I disable this call everything
>> works fine. This call really needs to be done in the background so how
>> can I make this work?
>>
>>> On 01/04/2017 09:32 AM, Erik de Hair wrote:
>>>> Hi,
>>>>
>>>> We have a view model with following action:
>>>>
>>>> @Action(domainEvent = WbaOrderFinishedEvent.class, publishing =
>>>> Publishing.DISABLED, commandPersistence =
>>>> CommandPersistence.NOT_PERSISTED)
>>>> @Override
>>>> public AbstractEndUserAccessSubscription finish(){
>>>>      ....
>>>> }
>>>>
>>>> The application is still trying to persist the action as a command
>>>> and it complains about the length of the target-column, while it
>>>> should be set to null for view models, isn't it?
>>>>
>>>> INSERT INTO Command
>>>>
>> (arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId)
>>>> VALUES (<''>,<2017-01-04
>>>> 09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store
>>>> value
>>>>
>> "*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4="
>>>> in column "target" that has maximum length of 2000. Please correct
>>>> your data!
>>>>
>>>> How to fix this?
>>>>
>>>> Thanks,
>>>> Erik
>>>>
>>>
>>
>>



Re: Prevent command from being persisted

Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Erik,

Looks like an error in BackgroundCommandServiceJdo [1].  It's setting the
child command's reference to the parent command, and then the latter gets
persisted due to persistence-by-reachability.

You can workaround this by creating your own version of
BackgroundCommandService2, with @DomainService(menuOrder="50") say so that
it is picked up first.  Copy the existing class and adjust.

Ideally the implementatation needs to find out the ObjectAction
corresponding to the parent Command, and check its CommandFacet.  That will
mean reaching deep into the Apache Isis metamodel, I think ... I don't
think there's any formal API for that I'm afraid.

Or, you could go for the cheap-n-cheerful approach which is to check for
the length of the targetStr of the parent Command, and set the child's
parent ref to null if too long.  You could use code similar to that in
CommandServiceJdo to do this [2]

Meantime I've raised an issue on the module [3].  PRs happily received if
you have the time to fix properly.

Thx
Dan


[1]
https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/BackgroundCommandServiceJdo.java#L117
[2]
https://github.com/isisaddons/isis-module-command/blob/master/dom/src/main/java/org/isisaddons/module/command/dom/CommandServiceJdo.java#L92
[3] https://github.com/isisaddons/isis-module-command/issues/14


On Wed, 4 Jan 2017 at 14:18 Erik de Hair <e....@pocos.nl> wrote:

>
> On 01/04/2017 10:14 AM, Erik de Hair wrote:
> > So now it seems an action in the registered domainEvent is persisted
> > as a command and while debugging I can see the finish()-action is it's
> > parent command. Will persisting the action from the domainEvent
> > trigger persistence of it's parent also, eventhough it shouldn't be
> > persisted? The targetStr-property of the finish()-command is not null.
> > Could that be messing things up?
> >
>
> It ís messing things up. The subscriber for the WbaOrderFinishedEvent
> starts another background-command. If I disable this call everything
> works fine. This call really needs to be done in the background so how
> can I make this work?
>
> >
> > On 01/04/2017 09:32 AM, Erik de Hair wrote:
> >> Hi,
> >>
> >> We have a view model with following action:
> >>
> >> @Action(domainEvent = WbaOrderFinishedEvent.class, publishing =
> >> Publishing.DISABLED, commandPersistence =
> >> CommandPersistence.NOT_PERSISTED)
> >> @Override
> >> public AbstractEndUserAccessSubscription finish(){
> >>     ....
> >> }
> >>
> >> The application is still trying to persist the action as a command
> >> and it complains about the length of the target-column, while it
> >> should be set to null for view models, isn't it?
> >>
> >> INSERT INTO Command
> >>
> (arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId)
> >> VALUES (<''>,<2017-01-04
> >> 09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store
> >> value
> >>
> "*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4="
> >> in column "target" that has maximum length of 2000. Please correct
> >> your data!
> >>
> >> How to fix this?
> >>
> >> Thanks,
> >> Erik
> >>
> >
> >
>
>
>

Re: Prevent command from being persisted

Posted by Erik de Hair <e....@pocos.nl>.
On 01/04/2017 10:14 AM, Erik de Hair wrote:
> So now it seems an action in the registered domainEvent is persisted 
> as a command and while debugging I can see the finish()-action is it's 
> parent command. Will persisting the action from the domainEvent 
> trigger persistence of it's parent also, eventhough it shouldn't be 
> persisted? The targetStr-property of the finish()-command is not null. 
> Could that be messing things up?
>

It ís messing things up. The subscriber for the WbaOrderFinishedEvent 
starts another background-command. If I disable this call everything 
works fine. This call really needs to be done in the background so how 
can I make this work?

>
> On 01/04/2017 09:32 AM, Erik de Hair wrote:
>> Hi,
>>
>> We have a view model with following action:
>>
>> @Action(domainEvent = WbaOrderFinishedEvent.class, publishing = 
>> Publishing.DISABLED, commandPersistence = 
>> CommandPersistence.NOT_PERSISTED)
>> @Override
>> public AbstractEndUserAccessSubscription finish(){
>>     ....
>> }
>>
>> The application is still trying to persist the action as a command 
>> and it complains about the length of the target-column, while it 
>> should be set to null for view models, isn't it?
>>
>> INSERT INTO Command 
>> (arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId) 
>> VALUES (<''>,<2017-01-04 
>> 09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store 
>> value 
>> "*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4=" 
>> in column "target" that has maximum length of 2000. Please correct 
>> your data!
>>
>> How to fix this?
>>
>> Thanks,
>> Erik
>>
>
>



Re: Prevent command from being persisted

Posted by Erik de Hair <e....@pocos.nl>.
So now it seems an action in the registered domainEvent is persisted as 
a command and while debugging I can see the finish()-action is it's 
parent command. Will persisting the action from the domainEvent trigger 
persistence of it's parent also, eventhough it shouldn't be persisted? 
The targetStr-property of the finish()-command is not null. Could that 
be messing things up?


On 01/04/2017 09:32 AM, Erik de Hair wrote:
> Hi,
>
> We have a view model with following action:
>
> @Action(domainEvent = WbaOrderFinishedEvent.class, publishing = 
> Publishing.DISABLED, commandPersistence = 
> CommandPersistence.NOT_PERSISTED)
> @Override
> public AbstractEndUserAccessSubscription finish(){
>     ....
> }
>
> The application is still trying to persist the action as a command and 
> it complains about the length of the target-column, while it should be 
> set to null for view models, isn't it?
>
> INSERT INTO Command 
> (arguments,completedAt,`exception`,executeIn,memberIdentifier,memento,parentTransactionId,`result`,startedAt,targetAction,targetClass,target,`timestamp`,`user`,transactionId) 
> VALUES (<''>,<2017-01-04 
> 09:13:53.264>,<'javax.jdo.JDOFatalUserException: Attempt to store 
> value 
> "*nl.pocos.dom.access.kpn.wba.order.WbaFiberOrderForm:PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPG1lbWVudG8-PGN1c3RvbWVyLmJvb2ttYXJrPm5sLnBvY29zLmRvbS5jb21wYW55LlBvcnRhbENvbXBhbnk6aV8xMDM8L2N1c3RvbWVyLmJvb2ttYXJrPjxjb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgxPC9jb25uZWN0aW9uQXJ0aWNsZS5ib29rbWFyaz48Y3VzdG9tZXJSZWZlcmVuY2U-a2xhbnRyZWZlcmVudGllPC9jdXN0b21lclJlZmVyZW5jZT48dGVjaG5vbG9neUltcGw-RnR0SDwvdGVjaG5vbG9neUltcGw-PGFydGljbGVQQy5ib29rbWFyaz5ubC5wb2Nvcy5kb20uYXJ0aWNsZS5BYnN0cmFjdEFydGljbGU6aV8xMzgwPC9hcnRpY2xlUEMuYm9va21hcms-PGNsYXNzT2ZTZXJ2aWNlUEM-U3RhbmRhcmQ8L2NsYXNzT2ZTZXJ2aWNlUEM-PGNvbm5lY3Rpb25BZGRyZXNzLmJvb2ttYXJrPipubC5wb2Nvcy5hcHBsaWIuQWRkcmVzczpQRDk0Yld3Z2RtVnljMmx2YmowaU1TNHdJaUJsYm1OdlpHbHVaejBpVlZSR0xUZ2lQejRLUEcxbGJXVnVkRzgtUEdodmRYTmxUblZ0WW1WeVBqRTFNand2YUc5MWMyVk9kVzFpWlhJLVBISmxjMmxrWlc1alpUNUZTVTVFU0U5V1JVNDhMM0psYzJsa1pXNWpaVDQ4YzNSeVpXVjBQa2RGVEVSU1QxQlRSVmRIUEM5emRISmxaWFEtUEhwcGNFTnZaR1UtTlRZeE5FRkZQQzk2YVhCRGIyUmxQand2YldWdFpXNTBiejQ9PC9jb25uZWN0aW9uQWRkcmVzcy5ib29rbWFyaz48Y29ubmVjdGlvblBvaW50RGV0YWlscz5beyJjdXJyZW50T2RmQWNjZXNzU2VydmljZUlkIjoiUkVGMDAwMTk3OTEyNCIsImZ1dHVyZU9kZkFjY2Vzc1NlcnZpY2VJZCI6IiIsImNvbm5lY3Rpb25UeXBlcyI6eyIwIjoiTm90IGluIHVzZSIsIjEiOiJGaXhlZCBsaW5lIHNlcnZpY2UiLCIyIjoiVGVsZXBob255IHNlcnZpY2UiLCIzIjoiTURGIGJyb2FkYmFuZCBzZXJ2aWNlIiwiNCI6IlNERiBicm9hZGJhbmQgc2VydmljZSIsIjUiOiJPREYgYnJvYWRiYW5kIHNlcnZpY2UiLCI2IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGJsb2NrZWQiLCI3IjoiT0RGIGJyb2FkYmFuZCBzZXJ2aWNlIGRlZmVjdCIsIjgiOiJVbmtub3duIHNlcnZpY2UiLCI5IjoiTm8gY2hhbmdlIiwiMTAiOiJNREYgQnVuZGxlIiwiMTEiOiJTREYgQnVuZGxlIn0sImN1cnJlbnRUeXBlT2ZDb25uZWN0aW9uIjoiNSIsImZ1dHVyZVR5cGVPZkNvbm5lY3Rpb24iOiI5In1dPC9jb25uZWN0aW9uUG9pbnREZXRhaWxzPjxuYXQ-ZmFsc2U8L25hdD48cG9ydGZvbGlvPldfQURTTDwvcG9ydGZvbGlvPjxzdGF0ZT5TVU1NQVJZX1BBR0U8L3N0YXRlPjx0ZWNobm9sb2d5PkZ0dEg8L3RlY2hub2xvZ3k-PG1heE5sc1R5cGU-NjwvbWF4TmxzVHlwZT48d2lzaERhdGU-MjAxNy0wMS0yNTwvd2lzaERhdGU-PG9yZGVyU2NlbmFyaW8-TmV3X0xpbmU8L29yZGVyU2NlbmFyaW8-PHNlcnZpY2VMZXZlbD5CRVNUX0VGRk9SVDwvc2VydmljZUxldmVsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3ROYW1lPlBpZXQgU25vdDwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0TmFtZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmU-KzMxNDAyMTM0NTc4PC9jb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RQaG9uZT48Y29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPiszMTQwMjEzNDU3OTwvY29ubmVjdGlvbkFkZHJlc3NDb250YWN0UGhvbmVBZGRpdGlvbmFsPjxjb25uZWN0aW9uQWRkcmVzc0NvbnRhY3RFbWFpbD5wZXRAcG9jb3Mubmw8L2Nvbm5lY3Rpb25BZGRyZXNzQ29udGFjdEVtYWlsPjx1bnRhZ2dlZD50cnVlPC91bnRhZ2dlZD48dm9pY2VQcmlvcml0eVBDPnRydWU8L3ZvaWNlUHJpb3JpdHlQQz48dm9pY2VQcmlvcml0eUFDPmZhbHNlPC92b2ljZVByaW9yaXR5QUM-PGluc3RhbGxTZXJ2aWNlPmZhbHNlPC9pbnN0YWxsU2VydmljZT48Yml0cmF0ZURvd24-MTAwMDAwMC4wPC9iaXRyYXRlRG93bj48Yml0cmF0ZVVwPjEwMDAwMDAuMDwvYml0cmF0ZVVwPjxmdHVBdENvbm5lY3Rpb25BZGRyZXNzPkZUVV9UWTAxPC9mdHVBdENvbm5lY3Rpb25BZGRyZXNzPjwvbWVtZW50bz4=" 
> in column "target" that has maximum length of 2000. Please correct 
> your data!
>
> How to fix this?
>
> Thanks,
> Erik
>