[Workflow] Add a line about the attribute type when persisted. #9156

Guikingone · 2018-01-28T08:11:22Z

By default, the attribute must be an array in order to allow PropertyAccess to update the state and content of this last one, if we need to persist it via Doctrine, the mapping must define an array.

javiereguiluz · 2018-03-18T19:07:10Z

@lyrixx could you please review this proposal? Thanks!

lyrixx · 2018-03-19T09:32:29Z

With a multiple marking store, it's indeed true.
But I'm not very confortable with this doc. The property name is currentPlace:

It's singular, but we says it should be an array
It's not the default name (marking), so it should be configured. Do we really want to overload the "getting started" documentation ?

Guikingone · 2018-03-22T18:00:16Z

@lyrixx In fact, I've noticed this "approach" after trying to persist the attribute, I can understand that it seems strange to do it.

I've don't see that it overload the getting started block ...

Maybe we can rewrite the default name using currentStage or currentPlace and redefine the one which is used here?

lyrixx · 2018-03-22T23:38:40Z

About the issue:

if a MultipleStateMarkingStore is used, the persisted state type should be an array. Or something that could represent many values (json_array, bit fields ...). Usually with doctrine, we use a json or json_array column.
if a SingleStateMarkingStore is used, the persisted state type could be a string
if something else is used, it's the responsibility of the creator of the "SomeThingElseMarkingStore" to know how to store the data

And juste to make thing really clear, the MarkingStore is not coupled to a Workflow / StateMachine.
A workflow, by nature will require a "MultipleMarkingStore". But if the workflow is "linear", there are not needs for a multiple marking store. But in 99.99% case, it will.
But as a subject managed by a StateMachine can be in only place, a SingleMarkingStore is enough.

javiereguiluz · 2018-04-25T13:13:49Z

Sadly this pull request has stalled. Should we reword it, create a different one or close it as "won't merge"? Thanks!

lyrixx · 2018-04-25T13:59:45Z

This need to be reworded I think ;)

Guikingone · 2018-04-25T16:37:55Z

Yes, I need to have time to work on the reword, I'm gonna take some time this weekend in order to work on this PR.

javiereguiluz · 2018-09-06T15:26:56Z

Friendly ping to not forget about this. Thanks!

Guikingone · 2018-09-11T06:23:22Z

@javiereguiluz Yes, need to take time this week to finish this PR.

Fix on the storage format (probably need to be reworded).

ndench

Looks good to me! Thanks for clarifying this.

noniagriconomie · 2018-12-20T17:18:34Z

workflow/usage.rst

+    If a ``multiple_state`` is used, the persisted state type should be an ``array``, 
+    using Doctrine, you can use ``json`` or ``json_array``. 
+
+    If a ``single_state`` is used, the persisted state type could be a string


Or it could be also an integer, but you need to implement a MarkingStoreInterface to convert from string to int the place.

I see more often values of a $status property of object stored as int in the database, not string
Explaining it here could be very usefull to inform that we can do it easily IMO :)

cc @Guikingone

Thanks for the feedback, I've added new lines about this case, can you review it and tell me if it's adapted? 🤔

Thanks 😊

An improvement has been made in order to explain the usage of an int via MarkingStoreInterface

javiereguiluz · 2019-01-02T12:18:37Z

Should we close this pull request without merging it? First, the mentioned json_array type was deprecated in Doctrine. Second, the edge-case mentioned in single_state looks very edgy to me and I don't think we should mention it. Thoughts? Thanks!

noniagriconomie · 2019-01-02T13:15:15Z

@javiereguiluz

maybe wait symfony/symfony#29146 to be merged? and after document all cases?

but i really think a documentation (with example) is a must have for this part
actually lof of people using the workflow are using it with symfony, and with database storage

having a use case could be a nice one :)

lyrixx · 2019-01-02T16:46:50Z

No It should not be closed. This PR is good 👍 Let's merge it (except for json_array)

Guikingone · 2019-01-02T16:53:04Z

No It should not be closed. This PR is good 👍 Let's merge it (except for json_array)

We could remove the json_array if it's a problem, not a big deal 😄

javiereguiluz · 2019-01-02T16:52:37Z

workflow/usage.rst

+    If a ``multiple_state`` is used, the persisted state type should be an ``array``, 
+    using Doctrine, you can use ``json`` or ``json_array``. 
+
+    If a ``single_state`` is used, the persisted state type could be a string, 


"could be a string" or "should be a string" ... we say "should be an array" in the previous paragraph.

javiereguiluz · 2019-01-02T16:53:25Z

workflow/usage.rst

+    be aware that you need to implement :class:`Symfony\\Component\\Workflow\\MarkingStore\\MarkingStoreInterface`
+    in order to transform the int back to something understandable by Workflow.

+    If something else is used, you're in charge of choosing the best storage format.


Does the previous tip related to MarkingStoreInterface apply in this case too? If yes, we must merge these two phrases.

@javiereguiluz yes it's apply to. So it should be merged

@Guikingone could you merge theses phrase? Thanks.

After that, IMHO, we will be OK to merge it

Improved, to be checked 🙂

javiereguiluz · 2019-01-02T16:55:34Z

workflow/usage.rst

+
+.. note::
+
+    If a ``multiple_state`` is used, the persisted state type should be an ``array``, 


This prhase needs some reword. It reads as "should be an array using Doctrine". Do you mean, a "PHP array" in the entity property and a "json" type in the @Column mapping?

javiereguiluz · 2019-01-02T16:58:49Z

workflow/usage.rst

    class BlogPost
    {
-        // This property is used by the marking store
+        // This property is used by the marking store, by default, Symfony "mark" this attribute as an array.


I don't understand what this means --> "Symfony mark this attribute as an array" Is this something that can only be understood if you use the Workflow component (which I don't) ... or is it supposed to be understood by all readers? Thanks!

May be this is better:

By default symfony set the marking as an array.

as or with, I don't know

javiereguiluz · 2019-03-28T15:15:27Z

@Guikingone please, rebase this to 3.4 so we can merge it. Thank you.

Guikingone · 2019-04-03T12:53:00Z

@noniagriconomie @lyrixx

Hi 👋

Can you please check one last time this PR before the final rebase, this way, we can close it, thanks :)

noniagriconomie · 2019-04-03T13:11:44Z

@Guikingone there are some changes/new feature arround this storage part of the workflow
cf symfony/symfony@59f20ad
maybe this PR need to be closed, or adapted

lyrixx

Thanks for your PR. I added few comments.

workflow/usage.rst

lyrixx · 2019-04-07T08:25:35Z

workflow/usage.rst

+    be aware that you need to implement :class:`Symfony\\Component\\Workflow\\MarkingStore\\MarkingStoreInterface`
+    in order to transform the int back to something understandable by Workflow.

+    If something else is used, you're in charge of choosing the best storage format.


@javiereguiluz yes it's apply to. So it should be merged

Co-Authored-By: Mathieu Santostefano <[email protected]>

noniagriconomie · 2019-05-12T07:32:47Z

workflow/usage.rst


+.. tip::
+
+    The ``type`` (default value ``single_state``) and ``arguments`` (default value ``marking``)


@Guikingone For 4.3+ this need to be removed no?
As single/multiple state are deprecated/removed in favor of method
This PR must be rewrite for method marking store IMO

lyrixx · 2019-09-10T14:30:06Z

The branch 3.3 is not maintained anymore. And this page does not exist anymore.
Thanks for working on this feature.
I opened #12295 to covert what you trying to achieve.

I thing we can close this PR and iterate on #12295

Thanks again for your work

fix(Attribute): fix on attribute type if persisted

35d531a

carsonbot added Status: Needs Review Workflow labels Jan 28, 2018

xabbuh added this to the 3.4 milestone Apr 20, 2018

javiereguiluz added the Waiting feedback label Apr 25, 2018

javiereguiluz added Status: Needs Work and removed Status: Needs Review Waiting feedback labels May 24, 2018

fix(storage): storage format

8bad73f

Fix on the storage format (probably need to be reworded).

carsonbot added Status: Needs Review and removed Status: Needs Work labels Oct 19, 2018

carsonbot removed the Status: Needs Review label Oct 29, 2018

ndench approved these changes Oct 29, 2018

View reviewed changes

carsonbot added the Status: Reviewed label Oct 29, 2018

noniagriconomie reviewed Dec 20, 2018

View reviewed changes

improvement(DB storage): improvement on type stored

41f5ea3

An improvement has been made in order to explain the usage of an int via MarkingStoreInterface

javiereguiluz added the Waiting feedback label Jan 2, 2019

javiereguiluz reviewed Jan 2, 2019

View reviewed changes

Guikingone added 3 commits January 2, 2019 18:16

fix(type): fix on both class and Doctrine type

63a7df4

fix(store): fix on store usage

664b5e3

fix(marking): fix on marking sentence

d1c0dd0

javiereguiluz removed the Waiting feedback label Mar 28, 2019

Guikingone force-pushed the patch-8 branch 2 times, most recently from 55b36e1 to d1c0dd0 Compare April 3, 2019 12:15

lyrixx reviewed Apr 7, 2019

View reviewed changes

wouterj added Status: Needs Work and removed Status: Reviewed labels Apr 7, 2019

[FEAT] wording

b9e3c0e

Co-Authored-By: Mathieu Santostefano <[email protected]>

carsonbot added Status: Needs Review and removed Status: Needs Work labels May 9, 2019

fix(wording): fix on multiple phrases

93afa79

noniagriconomie reviewed May 12, 2019

View reviewed changes

OskarStark closed this Sep 10, 2019


		.. note::

		If a ``multiple_state`` is used, the persisted state type should be an ``array``,


		.. tip::

		The ``type`` (default value ``single_state``) and ``arguments`` (default value ``marking``)

Uh oh!

[Workflow] Add a line about the attribute type when persisted. #9156

[Workflow] Add a line about the attribute type when persisted. #9156

Uh oh!

Conversation

Guikingone commented Jan 28, 2018

Uh oh!

javiereguiluz commented Mar 18, 2018

Uh oh!

lyrixx commented Mar 19, 2018

Uh oh!

Guikingone commented Mar 22, 2018

Uh oh!

lyrixx commented Mar 22, 2018

Uh oh!

javiereguiluz commented Apr 25, 2018

Uh oh!

lyrixx commented Apr 25, 2018

Uh oh!

Guikingone commented Apr 25, 2018

Uh oh!

javiereguiluz commented Sep 6, 2018

Uh oh!

Guikingone commented Sep 11, 2018

Uh oh!

ndench left a comment

Choose a reason for hiding this comment

Uh oh!

noniagriconomie Dec 20, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

javiereguiluz commented Jan 2, 2019

Uh oh!

noniagriconomie commented Jan 2, 2019

Uh oh!

lyrixx commented Jan 2, 2019

Uh oh!

Guikingone commented Jan 2, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lyrixx Jan 2, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

javiereguiluz commented Mar 28, 2019

Uh oh!

Guikingone commented Apr 3, 2019

Uh oh!

noniagriconomie commented Apr 3, 2019

Uh oh!

lyrixx left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

noniagriconomie May 12, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lyrixx commented Sep 10, 2019

Uh oh!

Uh oh!

noniagriconomie Dec 20, 2018 •

edited

Loading

lyrixx Jan 2, 2019 •

edited

Loading

noniagriconomie May 12, 2019 •

edited

Loading