eZ Community » Forums » eZ Publish 5 Platform » How to Handle Errors
expandshrink

How to Handle Errors

How to Handle Errors

Thursday 05 February 2015 4:18:29 pm - 10 replies

Hello eZ-Community,

i have developed a new bundle for our eZ5.x which creates new objects based of delivered xml. It could be, that creating those objects (articles, galleries, polls, etc.) fails.

Now i am wondering, how to handle this errors in best way. Currently i have lots of drafts in my dashboard cause the "import" is running with my useraccount at the moment.

Is there a good way to get rid of this unwanted drafts if an exception occurs?

Best regards,

Jacob

Modified on Thursday 05 February 2015 4:19:06 pm by Jacob Ester

Thursday 05 February 2015 9:55:03 pm

I'm not sure if this helps you 100%, but repository supports transactions.

So you would do something like $repository->beginTransaction() at the start, if everything goes well, you have $repository->commit(), and on exception handling $repository->rollback().

https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Repository/Repository.php#L902

 

Did you mean something like this?

Friday 06 February 2015 9:53:05 am

Hi Ivan,

 

i am also not sure, but i think not.

I am doing something as described here: https://doc.ez.no/display/EZP/3.+...id-3.ManagingContent-Creatingcontent

So i a creating a contencreatestruct and set all needed values. Than, as example i set some additional locations, but something fails (eg. this desired location doesnt exists (just as an example)). So as a result my locationcreatestruct will not be published but a draft with my a with the previously written values exist - only visible for me in my dashboard.

But it will be worse if i try to run an update later on this object. The new draft is based on the previously not published draft with its errors. So i am also not able to publish the new draft. 

In summary i am looking for a method to get rid of this "faulty" drafts in case of an exception.

But i will now have a deeper look if i could wrap the whole publishing process inside of an transaction.

 

Best regards,

Jacob

Friday 06 February 2015 1:45:09 pm

Quote from Jacob Ester :

Hi Ivan,

 

i am also not sure, but i think not.

I am doing something as described here: https://doc.ez.no/display/EZP/3.+...id-3.ManagingContent-Creatingcontent

So i a creating a contencreatestruct and set all needed values. Than, as example i set some additional locations, but something fails (eg. this desired location doesnt exists (just as an example)). So as a result my locationcreatestruct will not be published but a draft with my a with the previously written values exist - only visible for me in my dashboard.

But it will be worse if i try to run an update later on this object. The new draft is based on the previously not published draft with its errors. So i am also not able to publish the new draft. 

In summary i am looking for a method to get rid of this "faulty" drafts in case of an exception.

But i will now have a deeper look if i could wrap the whole publishing process inside of an transaction.

 

Best regards,

Jacob

Hi Jacob,

Well, that's exactly what repository's transaction takes care of. If there is an exception, rollback() cleans everything up, if everything goes well, the content actually gets published on commit().

I'd do something like this:

$repository = $this->getContainer()->get( 'ezpublish.api.repository' );
 
$repository->beginTransaction();
 
try{
$contentService = $repository->getContentService();
$locationService = $repository->getLocationService();
$contentTypeService = $repository->getContentTypeService();
$contentType = $contentTypeService->loadContentTypeByIdentifier( 'article' );
$contentCreateStruct = $contentService->newContentCreateStruct( $contentType, 'eng-GB' );
$contentCreateStruct->setField( 'title', 'My title' );
$locationCreateStruct= $locationService->newLocationCreateStruct( 2 );
$draft = $contentService->createContent( $contentCreateStruct, array( $locationCreateStruct ) );
$content = $contentService->publishVersion( $draft->versionInfo );
// add locations or whatnot
 
$repository->commit();
}
catch(\Exception $ex)
{
$repository->rollback();
}

Modified on Friday 06 February 2015 1:45:57 pm by Ivan Herak

Friday 06 February 2015 2:38:44 pm

This is indeed what transactions are for, allowing you to rollback if something went wrong during a several step operation. Not a concern here, but unfortunately not possible over REST, so there we might want to look into allowing bigger operations to be able to create draft, add locations and publish all in one atomic operation.

Modified on Friday 06 February 2015 2:39:15 pm by André R

Friday 27 February 2015 12:25:11 pm

Hi Guys,

thank you really much. At last question, and then im done with that blunk.gif Emoticon

It doesnt seem to be a good idea to use some kind of nested transactions.

As Example in pseudocode:

$repo->beginTransaction();
$article->handleContent(); //Content has inline images
foreach ($inlineImages as $key => $image) {
    $inlineImage = new Image($image);
    $inlineImage->publish();
}
$repo->commit();

Where Image is something like:

...
$repo->beginTransaction();
$contentType = $contentTypeService->loadContentTypeByIdentifier('image');
... 

and $image->publish(); is something like:

//create new draft
//publish new draft
$repo->commit(); //commit Image Transaction 

Not a real good example but i only want to ask, if it is possible to create a new transaction while inside of a transaction?

 

Best regards,

Jacob

Modified on Friday 27 February 2015 12:30:11 pm by Jacob Ester

Monday 02 March 2015 11:58:08 am

Hi,

nested transactions are ok, but as they are isolated and involve some overhead you should not use them for everting. In example above it seems you might be using it for read only operation ("Image is something like" ), if that is the case you can skip it there.

Best,
André 

Modified on Monday 02 March 2015 11:59:15 am by André R

Thursday 05 March 2015 3:23:08 pm

The default error handler for this is the built in error handler. We are going to make the function above the default error handler for the duration of the script.

It is possible to change the error handler to apply for only some errors, that way the script can handle different errors in different ways. However, in this example we are going to use our custom error handler for all errors:

set_error_handler("customError"blunk.gif Emoticon;

Since we want our custom function to handle all errors, the set_error_handler() only needed one parameter, a second parameter could be added to specify an error level.

Friday 20 March 2015 2:34:45 pm

We are using the legacy kernel for publishing to trigger our legacy workflows. Using transactions and doing some legacy-publishing seems to generate lots of fatal errors like 

Fatal error: Call to a member function attribute() on a non-object in ezpublish_legacy/extension/ezfind/search/plugins/ezsolr/ezsolr.php on line 478 or 

Fatal error: Call to a member function translationList() on a non-object in ezpublish_legacy/kernel/content/ezcontentoperationcollection.php on line 634

Has anyone already been successful with using transactions while publishing with the legacy-kernel?

Best regards,

Jacob

Saturday 21 March 2015 11:24:21 am

Looks like something is wrong in what eZ Find is being given... what's on line 478 of ezsolr.php ?

Tuesday 24 March 2015 12:05:38 am

As this thread started out regarding "platform stack" API transactions be aware platform stack and legacy stack uses two different database connections because they use different database drivers (typically pdo vs mysqli). Meaning they don't share transactions, which is why we try to make sure callbacks between the two kernels happen outside of transactions.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from