Make publishing of containers default to publishing the contents individually: Status History

Below is the history of changes to this idea's status. Return to the idea.

  • Accepted, Not Yet Planned

    No note was provided with this status update.

    Dragan Nanic

  • Under Community Review

    Note that an extension is available which allows you to publish a Publication or SG subtree as individual items: http://www.alchemywebstore.com/plugins/5a7d976ee4de0213a8e970d5

    This is both evidence of that such functionality is desired and a (temporary) solution at the same time.

    There seem to be several aspects involved here and it would be good to get a better picture on the exact requirements.

    1. Transactionality. Indeed, one of the reasons why a publish action is not immediately split into multiple small publish jobs is that the action is considered a single publish transaction which should succeed or fail entirely (with no side-effects in case of failure).  Note that there is a possibility to allow a given number of render failures as an exception here.  Are there cases where this transactionality itself is undesired?  Suppose all publish transactions can be done within a blink of an eye, regardless of their size, would there still be a reasons to split the publish action into multiple small publish transactions?
    2. Hogging of publisher capacity.  Indeed, using multiple large publish transactions you can hog the entire publisher capacity, making it impossible to give priority to a small-but-important publish job.  What if you could reserve one or more publisher threads for "individual item" publish jobs? Would that be a sufficient (or even better) solution for this problem?
    3. Transport Package size.  One publish transaction results in one transport package and there is a limit to the size of a tranport package. It may be necessary to split a publish action into several publish transactions for this reason. What if a publish transaction can have multiple transport packages and the size of each transport package will be kept under a configurable limit?
    4. Publish Transaction granularity. Assuming that reasons remain to create multiple Publish Transaction for a single publish action, what would the ideal granularity be?
      1. Individual ("leaf") items: Pages and Components (for DCPs)
      2. Organizational Items (single level rather than full subtrees). For example: when publishing a SG, separate Publish Transactions are created for that SG and all SGs below it.  Each Publish Transaction resolves to the Pages which are in that SG directly.
      3. Either; something that the user should be able to decide?
    5. Perceived performance. Note that resolving the items to publish can be quite expensive and may take a significant amount of time. Currently this happens in the background (in the publisher service); the user only has to await the first resolving step (where the Publish Transactions are created). Would it be acceptable if the user has to wait longer if he (or someone else) decides that many small Publish Transactions should be resolved/created? Or should it first create a single, large Publish Transaction which is later (asynchronously) split in smaller ones?
    6. Who decides? Is the decision on how to resolve something that the person doing the publish action should make or should that be specified by someone else (a sysadmin)? And on which level? System-wide? Per Publication? 
    Rick Pannekoek

  • Under Community Review

    Note that an extension is available which allows you to publish a Publication or SG subtree as individual items: http://www.alchemywebstore.com/plugins/5a7d976ee4de0213a8e970d5

    This is both evidence of that such functionality is desired and a (temporary) solution at the same time.

    There seem to be several aspects involved here and it would be good to get a better picture on the exact requirements.

    1. Transactionality. Indeed, one of the reasons why a publish action is not immediately split into multiple small publish jobs is that the action is considered a single publish transaction which should succeed or fail entirely (with no side-effects in case of failure).  Note that there is a possibility to allow a given number of render failures as an exception here.  Are there cases where this transactionality itself is undesired?  Suppose all publish transactions can be done within a blink of an eye, regardless of their size, would there still be a reasons to split the publish action into multiple small publish transactions?
    2. Hogging of publisher capacity.  Indeed, using multiple large publish transactions you can hog the entire publisher capacity, making it impossible to give priority to a small-but-important publish job.  What if you could reserve one or more publisher threads for "individual item" publish jobs? Would that be a sufficient (or even better) solution for this problem?
    3. Transport Package size.  One Publish Transaction results in one Transport Package and there is a limit to the size of a Tranport Package. It may be necessary to split a publish action into several publish transactions for this reason. What if a publish transaction can have multiple Transport Packages and the size of each Transport Package will be kept under a configurable limit?
    4. Publish Transaction granularity. Assuming that there remain reasons (besides #3) to create multiple Publish Transaction for a single publish action, what would the ideal granularity be?
      1. Individual ("leaf") items: Pages and Components (for DCPs)
      2. Organizational Items (single level rather than full subtrees). For example: when publishing a SG, separate Publish Transactions are created for that SG and all SGs below it.  Each Publish Transaction resolves to the Pages which are in that SG directly.
      3. Either; something that the user should be able to decide?
    5. Perceived performance. Note that resolving the items to publish can be quite expensive and may take a significant amount of time. Currently this happens in the background (in the publisher service); the user only has to await the first resolving step (where the Publish Transactions are created). Would it be acceptable if the user has to wait longer if he (or someone else) decides that many small Publish Transactions should be resolved/created? Or should it first create a single, large Publish Transaction which is later (asynchronously) split in smaller ones?
    6. Who decides? Is the decision on how to resolve something that the person doing the publish action should make or should that be specified by someone else (a sysadmin)? And on which level? System-wide? Per Publication? 
    Rick Pannekoek

  • Under Community Review

    Note that an extension is available which allows you to publish a Publication or SG subtree as individual items: http://www.alchemywebstore.com/plugins/5a7d976ee4de0213a8e970d5

    This is both evidence of that such functionality is desired and a (temporary) solution at the same time.

    There seem to be several aspects involved here and it would be good to get a better picture on the exact requirements.

    1. Transactionality. Indeed, one of the reasons why a publish action is not immediately split into multiple small publish jobs is that the action is considered a single publish transaction which should succeed or fail entirely (with no side-effects in case of failure).  Note that there is a possibility to allow a given number of render failures as an exception here.  Are there cases where this transactionality itself is undesired?  Suppose all publish transactions can be done within a blink of an eye, regardless of their size, would there still be a reasons to split the publish action into multiple small publish transactions?
    2. Hogging of publisher capacity.  Indeed, using multiple large publish transactions you can hog the entire publisher capacity, making it impossible to give priority to a small-but-important publish job.  What if you could reserve one or more publisher threads for "individual item" publish jobs? Would that be a sufficient (or even better) solution for this problem?
    3. Transport Package size.  One Publish Transaction results in one Transport Package and there is a limit to the size of a Tranport Package. It may be necessary to split a publish action into several Publish Transactions for this reason.
    4. Publish Transaction granularity. Assuming that there remain reasons (besides #3) to create multiple Publish Transaction for a single publish action, what would the ideal granularity be?
      1. Individual ("leaf") items: Pages and Components (for DCPs)
      2. Organizational Items (single level rather than full subtrees). For example: when publishing a SG, separate Publish Transactions are created for that SG and all SGs below it.  Each Publish Transaction resolves to the Pages which are in that SG directly.
      3. Either; something that the user should be able to decide?
    5. Perceived performance. Note that resolving the items to publish can be quite expensive and may take a significant amount of time. Currently this happens in the background (in the publisher service); the user only has to await the first resolving step (where the Publish Transactions are created). Would it be acceptable if the user has to wait longer if he (or someone else) decides that many small Publish Transactions should be resolved/created? Or should it first create a single, large Publish Transaction which is later (asynchronously) split in smaller ones?
    6. Who decides? Is the decision on how to resolve something that the person doing the publish action should make or should that be specified by someone else (a sysadmin)? And on which level? System-wide? Per Publication? 
    Rick Pannekoek

  • Under Community Review

    Note that an extension is available which allows you to publish a subtree as individual items: http://www.alchemywebstore.com/plugins/5a7d976ee4de0213a8e970d5

    This is both evidence of that such functionality is desired and a (temporary) solution at the same time.

    There seem to be several aspects involved here and it would be good to get a better picture on the exact requirements.

    1. Transactionality. Indeed, one of the reasons why a publish action is not immediately split into multiple small publish jobs is that the action is considered a single publish transaction which should succeed or fail entirely (with no side-effects in case of failure).  Note that there is a possibility to allow a given number of render failures as an exception here.  Are there cases where this transactionality itself is undesired?  Suppose all publish transactions can be done within a blink of an eye, regardless of their size, would there still be a reasons to split the publish action into multiple small publish transactions?
    2. Hogging of publisher capacity.  Indeed, using multiple large publish transactions you can hog the entire publisher capacity, making it impossible to give priority to a small-but-important publish job.  What if you could reserve one or more publisher threads for "individual item" publish jobs? Would that be a sufficient (or even better) solution for this problem?
    3. Transport Package size.  One Publish Transaction results in one Transport Package and there is a limit to the size of a Tranport Package. It may be necessary to split a publish action into several Publish Transactions for this reason.
    4. Publish Transaction granularity. Assuming that there remain reasons (besides #3) to create multiple Publish Transaction for a single publish action, what would the ideal granularity be?
      1. Individual ("leaf") items: Pages and Components (for DCPs)
      2. Organizational Items (single level rather than full subtrees). For example: when publishing a SG, separate Publish Transactions are created for that SG and all SGs below it.  Each Publish Transaction resolves to the Pages which are in that SG directly.
      3. Either; something that the user should be able to decide?
    5. Perceived performance. Note that resolving the items to publish can be quite expensive and may take a significant amount of time. Currently this happens in the background (in the publisher service); the user only has to await the first resolving step (where the Publish Transactions are created). Would it be acceptable if the user has to wait longer if he (or someone else) decides that many small Publish Transactions should be resolved/created? Or should it first create a single, large Publish Transaction which is later (asynchronously) split in smaller ones?
    6. Who decides? Is the decision on how to resolve something that the person doing the publish action should make or should that be specified by someone else (a sysadmin)? And on which level? System-wide? Per Publication? 
    Rick Pannekoek

  • New

    No note was provided with this status update.

    Dominic Cronin