Tech Writer Feedback Added to Migration Guide

This PR includes additional updates based on reviews by engineering and the tech writers.

I don’t know how these files ended up in the pull request, but they are not valid to the migration guide and I have not made any changes to these files nor will I be make any changes to those files

From: Veena @.>
Sent: Monday, November 6, 2023 5:53:16 AM
To: IBM/bamoe-docs @.>
Cc: Barry Lulas @.>; Author @.>
Subject: Re: [IBM/bamoe-docs] Tech Writer Feedback Added to Migration Guide (PR #52)
@veena-ux commented on this pull request.
Some minor changes, spellings and word usages.

In installation/docker-compose.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382816995:

-== Build
+== Prerequistes
Typo -> Prerequistes
Change -> Prerequisites

In installation/docker-compose.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382818450:

-Before building the image, please set the following environment variable like so:
Remove 'please'
Remove 'like so'
Re-written:
Before building the image, set the following environment variable.

In installation/docker-compose.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382819767:

-Before building the image, please set the following environment variable like so:
+You will need Docker and the Compose plugin in order to run the file. Refer to their web page for installation.
Remove 'in order' and retain to
Remove 'will'
Add 'the' before installation
Re-written:
You need the Docker and compose plugin to run the file. See the web page for installation.
Please note:
It's better to give a link to the web page so that the customer need not search for the web page.

In installation/docker-compose.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382822885:

== Run
-Run {CANVAS} with docker compose and current environment variables using pnpm:
+To Run {CANVAS} with docker compose follow these steps:
Provide comma(,) after compose

In installation/docker-compose.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382823667:

+. Download bamoe-9.0.0-docker-compose.zip from the https://www.ibm.com/support/pages/node/7001673[Support and Download Page].
+. Extract the bamoe-9.0.0-docker-compose.zip file.
+. In a terminal navigate to the extracted folder: bamoe-9.0.0docker-compose`.
Provide comma(,) after 'In a terminal'

In migration-guide/business-central.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382824603:

@@ -0,0 +1,149 @@
+include::../partials/attributes.adoc[]
+= Migrating from Business Central to IBM {DEV_TOOLS}

+== Overview
+
+Business Central is the previous generation web-based platform for authoring business automation assets such as data objects, rules, processes, cases, and planning entities.
+It included capabilities for monitoring, administration, and management of business automation assets.
included -> includes

In migration-guide/business-central.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382825494:

@@ -0,0 +1,149 @@
+include::../partials/attributes.adoc[]
+= Migrating from Business Central to IBM {DEV_TOOLS}

+== Overview
+
+Business Central is the previous generation web-based platform for authoring business automation assets such as data objects, rules, processes, cases, and planning entities.
+It included capabilities for monitoring, administration, and management of business automation assets.
+With the release of both IBM {DEV_TOOLS} and IBM {CANVAS}, most of the asset management capabilities were replaced or sometimes take a different approach altogether.
sometimes -> might

In migration-guide/business-central.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382841609:

+| Guided Rule | Decision (.rdrl) | Guided Technical Rule | {DEV_TOOLS} | Copy source from BC to new Technical Rule (.drl) file
+| Guided Rule Template | Decision (.template) | Template for guided rules | | {DEV_TOOLS} | Copy source from BC to new Technical Rule (.drl) file
+| Test Scenario (Legacy)| Decision (.scenario) | Legacy (guided) test scenario used for rule unit testing | Deprecated |

+|===
+
+
+[NOTE]
+====
+Test scenarios are not supported in {CANVAS} for now as it contains its own test scenario assets. There can be compatibility between the test scenarios.
+====
+
+== Migration of Deprecated Assets
+
+While all the guided editors are deprecated in {PRODUCT} v{VERSION}, your efforts are not lost by building those assets.
+Even though all guided editors have been deprecated in {PRODUCT} v{VERSION} you will not loose all your effort into building those
One sentence per line
Suggestion:
Though all the guided editors are deprecated in {PRODUCT} v{VERSION}, you do not loose all your effort into building those assets.

In migration-guide/business-central.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382843822:

+| Guided Decision Table (.gdst) | Guided Decisison Table | Export from BC to Decision Table Spreadsheet (.xls)
+| Guided Rule (.rdrl) | Technical Rule (.drl) | Copy source from BC to new Technical Rule (.drl) file
+| Rule Template (.template) | Technical Rule (.drl) | Copy source from BC to new Technical Rule (.drl) file
+|===

+== Copying the asset Source from Business Central
+
+All the guided assets are Drools Rule Language (.drl) files. A guided asset can be refactored into a non-guided asset by copying the source from the source tab in Business Central
+into a file with the file extension, . drl. Follow the examples to accomplish it.
+
+Examples
+
+.Guided Rule in Business Central
+image::../images/bc-example-guided-rule.png[Guided Rule in Business Central]
+
+As you can see from the figure 1, this is the default tab (Model) in Business Central’s guided rule editor. If you navigate to the Source tab, you can see that the guided rule is actually Drools Rule Language (DRL), like the following example:
Remove 'actually'
Instead replace it with 'a'
like.......you can see that the guided rule is a Drools Rule Language (DRL),

In migration-guide/business-central.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382859214:

+. Select the newly created .xls file in the Project Explorer
+. Select one of the Download options from the button bar
+. Add this file to the src/main/resources folder of your Maven project.

+As you can see from figure 1, this is the default tab (Model) in Business Central’s
+Guided decision table editor. If you navigate to the Source tab, you can see that the guided decision table is an editor view on the standard technical rule written using Drools Rule Language (DLR), as in the following example.
+
+.Guided Decision Table in Business Central (Source Tab)
+image::../images/bc-example-guide-dt-source.png[Guided Decision Table in Business Central]
+
+You now have a choice either to take the same approach like the guided rules or export the table to Excel format by clicking (Convert to XLS), as in the following example.
+
+.Exporting a Guided Decision Table in Business Central
+image::../images/bc-example-guided-dt-export.png[Exporting a Guided Decision Table in Business Central]
+
+Once the table has been converted to XLS format, the new file is added to the Business Central Project Explorer view:
Replace 'Once' with 'After'
Replace 'has been' -> is
Replace colon(:) with full stop(.) at the end of the sentence
Reasons:
Once is to mean once, twice, thrice...usage in documentation
has been - most of the time we use the present tense instead of past tense unless in unavoidable cases

In migration-guide/business-central.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382864885:

+Guided decision table editor. If you navigate to the Source tab, you can see that the guided decision table is an editor view on the standard technical rule written using Drools Rule Language (DLR), as in the following example.

+.Guided Decision Table in Business Central (Source Tab)
+image::../images/bc-example-guide-dt-source.png[Guided Decision Table in Business Central]
+
+You now have a choice either to take the same approach like the guided rules or export the table to Excel format by clicking (Convert to XLS), as in the following example.
+
+.Exporting a Guided Decision Table in Business Central
+image::../images/bc-example-guided-dt-export.png[Exporting a Guided Decision Table in Business Central]
+
+Once the table has been converted to XLS format, the new file is added to the Business Central Project Explorer view:
+
+.Converted Guided Decision Table in Business Central
+image::../images/bc-example-guided-dt-export-navigator.png[Converting a Guided Decision Table in Business Central]
+
+From there it is simply a matter of selecting the converted file and pressing one of the Download buttons in Business Central, which will download the converted spreadsheet file to your local machine so the file can be added to your project's src/main/resources folder of your Maven project.
From there -> mention where
Replace or remove 'simply' (we do not use such words in documentation)
Replace 'which will download' -> which downloads
so the file -> so that the file
'your' repeated -> remove any one
Suggestion:
You may want to re-write this whole sentence.
My suggested content:
Select the converted file and choose one of the Download buttons in Business Central, which download the converted spreadsheet file to your local machine. You can add this file to src/main/resources folder of your Maven project.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382871926:

@@ -0,0 +1,374 @@
+= Migrating to the Latest Version of Drools Rule Language (DRL)
+include::../partials/attributes.adoc[]

+When migrating to {PRODUCT_LONG} v{PRODUCT_VERSION} you may be faced with the task of migrating your technical rules, which are currently represented by Drools Rule Language (DRL) files.
When migrating -> When you are migrating to
Replace 'may' -> not the suggested term - Instead use 'might'
Replace 'you may be faced'
The sentence is not very clear, you may want to re-write.
My suggested content:
You might have to migrate your technical rules, which are currently represented by Drools Rule Language (DRL) files while migrating to {PRODUCT_LONG} v{PRODUCT_VERSION}.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382872943:

@@ -0,0 +1,374 @@
+= Migrating to the Latest Version of Drools Rule Language (DRL)
+include::../partials/attributes.adoc[]

+When migrating to {PRODUCT_LONG} v{PRODUCT_VERSION} you may be faced with the task of migrating your technical rules, which are currently represented by Drools Rule Language (DRL) files.
+
+== Overview
+
+This section describes how to migrate your technical rules in order to take advantage of the new features of Drools Rule Language (DRL) v8.
Remove 'in order' and retain 'to'
to take advantage -> to make use of the
v8 -> Version 8.0

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382886292:

@@ -0,0 +1,374 @@
+= Migrating to the Latest Version of Drools Rule Language (DRL)
+include::../partials/attributes.adoc[]

+When migrating to {PRODUCT_LONG} v{PRODUCT_VERSION} you may be faced with the task of migrating your technical rules, which are currently represented by Drools Rule Language (DRL) files.
+
+== Overview
+
+This section describes how to migrate your technical rules in order to take advantage of the new features of Drools Rule Language (DRL) v8.
+It should be noted that {PRODUCT_SHORT} v{PRODUCT_VERSION} is based, in part, on Drools Rule Language v8 and supports the previous version of the DRL language API's as well as syntax, so it may not be necessary to migrate your rules at all unless there is a new language feature that you'd like to take advantage of.
should -> not the suggested term - use 'must' instead (unless it does not mean so)
Replace 'as well as' with 'and'
Replace 'you'd' -> not suggested
Replace 'so it may not'
My suggested content:
The {PRODUCT_SHORT} v{PRODUCT_VERSION} is partly based on Drools Rule Language Version 8.0, and supports the previous version of the DRL language API's and syntax. Hence, it might not be necessary to migrate your rules except for a new language feature that you want to use.
OR
Note that the {PRODUCT_SHORT} v{PRODUCT_VERSION} is partly based on Drools Rule Language Version 8.0, and supports the previous version of the DRL language API's and syntax. Hence, it might not be necessary to migrate your rules except for a new language feature that you want to use.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382890027:

@@ -0,0 +1,374 @@
+= Migrating to the Latest Version of Drools Rule Language (DRL)
+include::../partials/attributes.adoc[]

+When migrating to {PRODUCT_LONG} v{PRODUCT_VERSION} you may be faced with the task of migrating your technical rules, which are currently represented by Drools Rule Language (DRL) files.
+
+== Overview
+
+This section describes how to migrate your technical rules in order to take advantage of the new features of Drools Rule Language (DRL) v8.
+It should be noted that {PRODUCT_SHORT} v{PRODUCT_VERSION} is based, in part, on Drools Rule Language v8 and supports the previous version of the DRL language API's as well as syntax, so it may not be necessary to migrate your rules at all unless there is a new language feature that you'd like to take advantage of.
+
+== Prerequisites
+
+The following tools are required in order to migrate to {PRODUCT_SHORT} v{VERSION}:
Remove 'in order' and retain 'to'
Suggested content:
The following tools are required to migrate to the {PRODUCT_SHORT} v{VERSION}:

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382894594:

+When migrating to {PRODUCT_LONG} v{PRODUCT_VERSION} you may be faced with the task of migrating your technical rules, which are currently represented by Drools Rule Language (DRL) files.

+== Overview
+
+This section describes how to migrate your technical rules in order to take advantage of the new features of Drools Rule Language (DRL) v8.
+It should be noted that {PRODUCT_SHORT} v{PRODUCT_VERSION} is based, in part, on Drools Rule Language v8 and supports the previous version of the DRL language API's as well as syntax, so it may not be necessary to migrate your rules at all unless there is a new language feature that you'd like to take advantage of.
+
+== Prerequisites
+
+The following tools are required in order to migrate to {PRODUCT_SHORT} v{VERSION}:
+
+include::../partials/prerequisites.adoc[]
+
+== Maven Dependencies
+
+Typical Drools v6 or early Drools v7 projects have pom.xml dependencies like this:
v6 -> Version 6.0
v7 -> Version 7.0
Remove -> Typical
Replace or remove 'have'
Suggestion:
The pom.xml dependencies of Drools Version 6.0 and Version 7.0 are as follows:

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382899388:

   <groupId>org.drools</groupId>

   <artifactId>drools-core</artifactId>

   <version>${version.org.drools}</version>

   <groupId>org.drools</groupId>

   <artifactId>drools-compiler</artifactId>

   <version>${version.org.drools}</version>

+----
+
+But since Drools v7.45.0, drools-engine and drools-engine-classic have been introduced as aggregator dependencies.
+The dependencies drools-engine-classic, drools-mvel are deprecated starting with Drools v8, hence use drools-engine as in the following example:
Drools v8 -> Drools Version 8.0

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382899409:

+

   <groupId>org.drools</groupId>

   <artifactId>drools-core</artifactId>

   <version>${version.org.drools}</version>

   <groupId>org.drools</groupId>

   <artifactId>drools-compiler</artifactId>

   <version>${version.org.drools}</version>

+----
+
+But since Drools v7.45.0, drools-engine and drools-engine-classic have been introduced as aggregator dependencies.
But since - > not right usage here - May be use 'As'
v7.45.0 -> Version 7.45.0
Replace 'have been'
Suggested content:
As Drools Version 7.45.0, 'drools-engine and 'drools-engine-classic' are introduced as aggregator dependencies.
Clarification:
Not sure if this sentence is part of previous sentence. Looks disconnected.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382902753:

+But since Drools v7.45.0, drools-engine and drools-engine-classic have been introduced as aggregator dependencies.
+The dependencies drools-engine-classic, drools-mvel are deprecated starting with Drools v8, hence use drools-engine as in the following example:
+
+[source,xml]
+----
+

   <groupId>org.drools</groupId>

   <artifactId>drools-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
Drools v8 -> Drools Version 8.0
Remove 'some'
Replace 'so you may find some'
Suggested content:
Drools Version 8.0 includes module refactoring and hence you might find it difficult to collect dependencies.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382904749:

+But since Drools v7.45.0, drools-engine and drools-engine-classic have been introduced as aggregator dependencies.
+The dependencies drools-engine-classic, drools-mvel are deprecated starting with Drools v8, hence use drools-engine as in the following example:

+[source,xml]
+----
+

   <groupId>org.drools</groupId>

   <artifactId>drools-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
+This aggregator dependency will certainly help.
This -> The
Replace 'will certainly help'
Suggested content:
The aggregator dependency definitely helps.
Suggestion for the whole paragraph:
As the Drools Version 8.0 includes module refactoring, it might be difficulty to collect the dependencies and hence you can make use of the aggregator dependencies.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382909928:

+----
+

   <groupId>org.drools</groupId>

   <artifactId>drools-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
+This aggregator dependency will certainly help.
+
+== Rule Units
+
+As previously introduced, using Rule Units are a recommended style for implementing rules in Drools v8.
As previously introduced -> As introduced earlier
Drools v8 -> Drools Version 8.0

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382917070:

+

   <groupId>org.drools</groupId>

   <artifactId>drools-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
+This aggregator dependency will certainly help.
+
+== Rule Units
+
+As previously introduced, using Rule Units are a recommended style for implementing rules in Drools v8.
+It will require some modifications to your codebase, but if you are going to develop cloud-native applications, Rule Units are recommended, because Kogito also works with Rule Units.
Replace 'It will require some' -> It requires modifications
Also mention what requires modifications
Remove 'going'
Suggested content:
Assuming it is Rule units......
Rule units require modifications to your codebase. If you are developing cloud-native applications, Rule Units are recommended, as it supports Kogito.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382918754:

   <groupId>org.drools</groupId>

   <artifactId>drools-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
+This aggregator dependency will certainly help.
+
+== Rule Units
+
+As previously introduced, using Rule Units are a recommended style for implementing rules in Drools v8.
+It will require some modifications to your codebase, but if you are going to develop cloud-native applications, Rule Units are recommended, because Kogito also works with Rule Units.
+Rule units represent a purely declarative approach to partition a rules set into smaller units, binding different data sources to those units and orchestrate the execution of the individual
Remove 'purely'
Sentence looks incomplete. You may want to re-write it.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382920055:

   <groupId>org.drools</groupId>

   <artifactId>drools-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
+This aggregator dependency will certainly help.
+
+== Rule Units
+
+As previously introduced, using Rule Units are a recommended style for implementing rules in Drools v8.
+It will require some modifications to your codebase, but if you are going to develop cloud-native applications, Rule Units are recommended, because Kogito also works with Rule Units.
+Rule units represent a purely declarative approach to partition a rules set into smaller units, binding different data sources to those units and orchestrate the execution of the individual
+unit. A rule unit is an aggregate of data sources, global variables and rules.
comma(,) required after variables -> global variables, and rules

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382920876:

   <version>${version.org.drools}</version>

+----
+
+Drools v8 included some module refactoring, so you may find some difficulty in collecting dependencies.
+This aggregator dependency will certainly help.
+
+== Rule Units
+
+As previously introduced, using Rule Units are a recommended style for implementing rules in Drools v8.
+It will require some modifications to your codebase, but if you are going to develop cloud-native applications, Rule Units are recommended, because Kogito also works with Rule Units.
+Rule units represent a purely declarative approach to partition a rules set into smaller units, binding different data sources to those units and orchestrate the execution of the individual
+unit. A rule unit is an aggregate of data sources, global variables and rules.
+
+In order to utilize Rule Units, simply add the following dependency, which is required for using Rule Unit API's:
Remove -> In order - Start with To
Remove -> simply

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382924563:

+unit. A rule unit is an aggregate of data sources, global variables and rules.

+In order to utilize Rule Units, simply add the following dependency, which is required for using Rule Unit API's:
+
+[source,xml]
+----
+

   <groupId>org.drools</groupId>

   <artifactId>drools-ruleunits-engine</artifactId>

   <version>${version.org.drools}</version>

+----
+
+Regarding related Java API usage, in Drools v7, you create a KieSession from rule assets.
Replace -> Regarding
Remove -> Then
Suggestion:
For the related Java API usage in Drools Version 7.0, you can create a KieSession from the rule assets, and insert facts and fire rules as displayed in the following example:

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382928658:

+[source,java]
+----
+KieServices ks = KieServices.Factory.get();
+KieContainer kcontainer = ks.getKieClasspathContainer();
+KieBase kbase = kcontainer.getKieBase();
+KieSession ksession = kbase.newKieSession();
+try {

ksession.insert(new Measurement("color", "red"));
ksession.insert(new Measurement("color", "green"));
ksession.fireAllRules();
+} finally {
ksession.dispose();
+}
+----

+However, using Rule Unit API's, the resulting Java snippet would be like this:
using -> by using
Replace -> would be like this
Suggestion:
However, by using the Rule Unit API's, the resulting Java snippet is displayed as follows:

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382988218:

+.Rule Unit API
+[source,java]
+----
+MeasurementUnit measurementUnit = new MeasurementUnit();
+RuleUnitInstance instance = RuleUnitProvider.get().createRuleUnitInstance(measurementUnit);

+try {

measurementUnit.getMeasurements().add(new Measurement("color", "red"));
measurementUnit.getMeasurements().add(new Measurement("color", "green"));
instance.fire();
+} finally {
instance.dispose();
+}
+----

+In Rule Unit, instantiate RuleUnitInstance instead of KieSession. Add facts to DataSource property instead of insert. Generic KIE API calls (e.g. KieServices, KieContainer, KieBase … ) are no longer needed. Instead, one more class Unit has to be defined:
Replace e.g. -> for example,
are no longer needed -> not required anymore
Instead, one more class Unit has to be defined -> Define one more class unit instead.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382992395:

public MeasurementUnit(DataStore measurements) {

   this.measurements = measurements;

}

public DataStore getMeasurements() {

   return measurements;

}

public Set getControlSet() {

   return controlSet;

}
+}
+----

+This Rule Unit class associates rules (DRL) and inserted facts (DataSource), so it helps you to manage the relationship.
so it helps -> and hence helps

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382993023:

public MeasurementUnit(DataStore measurements) {

   this.measurements = measurements;

}

public DataStore getMeasurements() {

   return measurements;

}

public Set getControlSet() {

   return controlSet;

}
+}
+----

+This Rule Unit class associates rules (DRL) and inserted facts (DataSource), so it helps you to manage the relationship.
+In addition to the API, the DRL syntax style also changes from traditional DRL, as in the following example:
as in the following example -> as displayed in the following example

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382995952:

+to Rule Unit DRL, as in the following example:

+.Rule Unit DRL
+[source,drl]
+----
+unit MeasurementUnit;
+
+rule "will execute per each Measurement having ID color"
+when

  /measurements[ id == "color", $colorVal : val ]

+then

  controlSet.add($colorVal);

+end
+----
+
+Firstly, declare unit, don't need to declare global, because controlSet is a field of MeasurementUnit.
Firstly -> Initially
don't need to declare global -> do not declare it as 'global'

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382997319:

+.Rule Unit DRL
+[source,drl]
+----
+unit MeasurementUnit;
+
+rule "will execute per each Measurement having ID color"
+when

  /measurements[ id == "color", $colorVal : val ]

+then

  controlSet.add($colorVal);

+end
+----
+
+Firstly, declare unit, don't need to declare global, because controlSet is a field of MeasurementUnit.
+Traditional global usage would become the Unit's field.
Replace 'would'
usage would become -> usage becomes

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382997931:

+----
+unit MeasurementUnit;

+rule "will execute per each Measurement having ID color"
+when

  /measurements[ id == "color", $colorVal : val ]

+then

  controlSet.add($colorVal);

+end
+----
+
+Firstly, declare unit, don't need to declare global, because controlSet is a field of MeasurementUnit.
+Traditional global usage would become the Unit's field.
+In addition, the main difference is OOPath notation in left hand side (LHS) of the rule.
+It is described in detail at Rule conditions in DRL.
+You should change from the class name (Measurement) to the DataSource property name in the Unit class (measurements).
should -> must

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1382999961:

+.Rule Unit DRL
+[source,drl]
+----
+unit MeasurementUnit;

+rule "Insert another Measurement"
+when

  /measurements[ id == "color", $colorVal : val ]

+then

  measurements.add(new Measurement("monochrome", "false"));

+end
+----
+
+[NOTE]
+====
+You don't need to re-write update, modify and delete, because they work for a fact in its DataSource expectedly.
You don't need -> You need not

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383005024:

+[source,drl]
+----
+unit MeasurementUnit;

+rule "Insert another Measurement"
+when

  /measurements[ id == "color", $colorVal : val ]

+then

  measurements.add(new Measurement("monochrome", "false"));

+end
+----
+
+[NOTE]
+====
+You don't need to re-write update, modify and delete, because they work for a fact in its DataSource expectedly.
+These changes are not negligible, but hopefully, as this migration guide demonstrated, they are not so difficult to implement either.
Remove hopefully
'they' work - you may substitute the actual word
Suggestion:
You need not re-write, update, modify or delete because they work for a fact in its DataSource as expected. These changes are not negligible but not difficult to implement either.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383008657:

+end
+----

+[NOTE]
+====
+You don't need to re-write update, modify and delete, because they work for a fact in its DataSource expectedly.
+These changes are not negligible, but hopefully, as this migration guide demonstrated, they are not so difficult to implement either.
+====
+
+== Migration from non-executable model to executable model
+
+The drools-engine-classic and drools-mvel dependencies execute rules with non executable model.
+drools-engine executes rules with executable model.  The executable model allows the user to pre-compile the model so that at runtime sessions are easier to create, basically speeding up the entire rule execution process.
+In general, from an external perspective, rule evaluation and rule consequence execution results can be expected to be the same using either the non-executable model or the executable model.
+You may however encounter a few edge cases during compile time or runtime.
+If you find any issues, please report them.
Remove 'please'
Question:
Report where? Please mention.

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383012502:

+[source,drl]
+----
+global MyUtils myUtils;

+rule Rule1
+dialect "mvel"
+when

$p : Person()
+then
myUtils.doWork((String) $p.age )));
+end
+----

+This rule can be built with non-executable model even if $p.age is int which is not acceptable in Java syntax.
+
+With executable model, the rule fails with a build error: Cannot cast from int to String, so in this case, the rule can be easily fixed by using valid Java syntax.
Replace 'so in this case' -> hence
Remove 'easily'

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383016518:

+For example:

+[source,drl]
+----
+rule Rule1

no-loop true
when
$fact : Fact( str == "ADD", $val : "100" )
then
modify($fact) {

 bdList.add($val);

}
+end
+----

+The non-executable model allows to add a String object to bdList even if Fact.bdList is List<BigDecimal> which is not acceptable in Java syntax.
allows to -> allows you to or the user to

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383017838:

+[source,drl]
+----
+rule Rule1

no-loop true
when
$fact : Fact( str == "ADD", $val : "100" )
then
modify($fact) {

 bdList.add($val);

}
+end
+----

+The non-executable model allows to add a String object to bdList even if Fact.bdList is List<BigDecimal> which is not acceptable in Java syntax.
+With executable model, the rule fails with a build error The method add(BigDecimal) in the type List<BigDecimal> is not applicable for the arguments (String).
comma(,) after build error required

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383019428:

+[source,drl]
+----
+rule Rule1

no-loop true
when
$fact : Fact( str == "ADD", $val : "100" )
then
modify($fact) {

 bdList.add($val);

}
+end
+----

+The non-executable model allows to add a String object to bdList even if Fact.bdList is List<BigDecimal> which is not acceptable in Java syntax.
+With executable model, the rule fails with a build error The method add(BigDecimal) in the type List<BigDecimal> is not applicable for the arguments (String).
+In this case, the rule can be easily fixed by using valid Java syntax.
Remove 'In this case' or replace
Remove 'easily'
OR
You can fix the rule by using valid Java syntax

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383019895:

+For example:

+[source,drl]
+----
+...
+then

modify($fact) {
bdList.add(new BigDecimal($val));
}
+end
+----

+=== Invalid Coercion
+
+For example, Java allows coercion from int to long.
+However, Java doesn't allow coercion from int to Long.
doesn't -> does not

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383020500:

+[source,drl]
+----
+...
+then

modify($fact) {
bdList.add(new BigDecimal($val));
}
+end
+----

+=== Invalid Coercion
+
+For example, Java allows coercion from int to long.
+However, Java doesn't allow coercion from int to Long.
+If you have the rule to call the setWrapperLong method which accepts Long:
Replace 'have'

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383020904:

+For example, Java allows coercion from int to long.
+However, Java doesn't allow coercion from int to Long.
+If you have the rule to call the setWrapperLong method which accepts Long:

+[source,drl]
+----
+rule Rule1
+dialect "mvel"
+when

$f : Fact()
+then
$f.setWrapperLong(10);
+end
+----

+The non-executable model coerces 10 to Long, so it doesn't throw an Exception.
doesn't -> does not

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383021518:

+However, Java doesn't allow coercion from int to Long.
+If you have the rule to call the setWrapperLong method which accepts Long:

+[source,drl]
+----
+rule Rule1
+dialect "mvel"
+when

$f : Fact()
+then
$f.setWrapperLong(10);
+end
+----

+The non-executable model coerces 10 to Long, so it doesn't throw an Exception.
+However, the executable model throws a build error: The method setWrapperLong(Long) in the type Fact is not applicable for the arguments (int).
Replace (:) with (,)

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383021821:

+If you have the rule to call the setWrapperLong method which accepts Long:

+[source,drl]
+----
+rule Rule1
+dialect "mvel"
+when

$f : Fact()
+then
$f.setWrapperLong(10);
+end
+----

+The non-executable model coerces 10 to Long, so it doesn't throw an Exception.
+However, the executable model throws a build error: The method setWrapperLong(Long) in the type Fact is not applicable for the arguments (int).
+In this case, the rule can be easily fixed by using valid Java syntax. For example:
Change 'In this case'
Remove 'easily'

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383025101:

  private final boolean adBlueRequired;

+----
+
+.Rule
+[source,drl]
+----
+rule Rule1

  when

          $v : DieselCar(motor.adBlueRequired == true)

  then

          // do something

+end
+----
+
+The non-executable model can dynamically resolve that motor is DieselEngine so the rule works.
resolve that motor is DieselEngine -> not clear
Remove so or replace it with 'hence'

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383026741:

private final boolean adBlueRequired;

+----
+
+.Rule
+[source,drl]
+----
+rule Rule1

  when

          $v : DieselCar(motor.adBlueRequired == true)

  then

          // do something

+end
+----
+
+The non-executable model can dynamically resolve that motor is DieselEngine so the rule works.
+However, the executable model resolves motor to TEngine, so a build error is thrown:  Unknown field adBlueRequired on TEngine.
Replace 'so'
comma after thrown (reason ->to maintain consistency across the documentation)

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383029741:

+----

+.Rule
+[source,drl]
+----
+rule Rule1

  when

          $v : DieselCar(motor.adBlueRequired == true)

  then

          // do something

+end
+----
+
+The non-executable model can dynamically resolve that motor is DieselEngine so the rule works.
+However, the executable model resolves motor to TEngine, so a build error is thrown:  Unknown field adBlueRequired on TEngine.
+In this case, the rule can be fixed by specifying the subtype with the # operator.
Replace 'In this case' or remove it
So the sentence can be:
The rule can be fixed .....

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383036187:

+The main objective of {PRODUCT_SHORT} is to help you mould a set of business processes and decisions into your own domain-specific cloud-native set of services.

+== Overview
+
+This section describes migration of existing applications to version {PRODUCT_VERSION} of {PRODUCT_LONG}.
+
+== Prerequisites
+
+The following tools are required to migrate to {PRODUCT_SHORT} v{VERSION}:
+
+include::../partials/prerequisites.adoc[]
+
+== Procedure
+
+While it is feasible to migrate an existing Knowledge Jar (KJAR) project, t is highly recommended to start your project from scratch, since the Maven configuration for {PRODUCT_SHORT} v{VERSION}
+is significantly different from that of {PRODUCT_SHORT} v {VERSION_OLD} or even {RH_DM} v7.  It is to note that the process is relatively simple as it is driven by Maven, and Quarkus specifically.
Remove 'even'

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383040004:

+This section describes migration of existing applications to version {PRODUCT_VERSION} of {PRODUCT_LONG}.

+== Prerequisites
+
+The following tools are required to migrate to {PRODUCT_SHORT} v{VERSION}:
+
+include::../partials/prerequisites.adoc[]
+
+== Procedure
+
+While it is feasible to migrate an existing Knowledge Jar (KJAR) project, t is highly recommended to start your project from scratch, since the Maven configuration for {PRODUCT_SHORT} v{VERSION}
+is significantly different from that of {PRODUCT_SHORT} v {VERSION_OLD} or even {RH_DM} v7.  It is to note that the process is relatively simple as it is driven by Maven, and Quarkus specifically.
+
+To start with, generate a new Maven project so that you have a place to migrate your existing business automation assets into the new {PRODUCT_SHORT} architecture.
+There are several ways to create Maven projects, however however, it is better to use a published Maven plugin.
+To do that, ensure that you first setup Maven project.To do that, ensure that you first setup your  Maven project properly:
delete extra space between 'your Maven'

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383051096:

+This section describes migration of existing applications to version {PRODUCT_VERSION} of {PRODUCT_LONG}.

+== Prerequisites
+
+The following tools are required to migrate to {PRODUCT_SHORT} v{VERSION}:
+
+include::../partials/prerequisites.adoc[]
+
+== Procedure
+
+While it is feasible to migrate an existing Knowledge Jar (KJAR) project, t is highly recommended to start your project from scratch, since the Maven configuration for {PRODUCT_SHORT} v{VERSION}
+is significantly different from that of {PRODUCT_SHORT} v {VERSION_OLD} or even {RH_DM} v7.  It is to note that the process is relatively simple as it is driven by Maven, and Quarkus specifically.
+
+To start with, generate a new Maven project so that you have a place to migrate your existing business automation assets into the new {PRODUCT_SHORT} architecture.
+There are several ways to create Maven projects, however however, it is better to use a published Maven plugin.
+To do that, ensure that you first setup Maven project.To do that, ensure that you first setup your  Maven project properly:
Looks like this sentence is a kind of repetition:
To do that, ensure that you first setup Maven project.To do that, ensure that you first setup your Maven project properly:
P.S:
You may want to change or re-write it.
Space after project is required.

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383060410:

+Maven's default settings.xml is a template with comments and examples so you can quickly tweak it to match your needs.
+If you are looking to learn more about how to manage your various Maven settings, visit the https://maven.apache.org/settings.html[Maven Settings Reference].
+====

+By acquiring the knowledge from {PRODUCT} Version 8.0 or Red Hat Version 7.0, you might be familiar with product dependencies hosted by https://maven.repository.redhat.com/ga/com/redhat/ba/[Red Hat's Maven repository].
+However this is no longer needed as the product dependencies are now hosted by https://central.sonatype.com/search?q=bamoe[Maven Central].
+There is no need to include an additional repository in pom.xml or settings.xml.
+
+=== Step 2: Generate a New Maven Project using Apache Maven
+
+Now that the Maven is configured, you can move to the next step to generate a new Maven project:
+
+[start=1]
+. In a terminal window, create a new local folder for the new Maven project, for example: /Users/developer, and navigate to the folder.
+
+. Create the project in Quarkus by using the following commands.  This will create a Quarkus project called my-sample-decision-service, which is versioned 1.0.0-SNAPSHOT, including the extensions kogito-quarkus, dmn, resteasy-reactive-jackson, quarkus-smallrye-openapi, and quarkus-smallrye-health.
This will create -> This creates

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383064992:

+mvn io.quarkus:quarkus-maven-plugin:2.16.7.Final:create \

-DprojectGroupId=com.ibm.bamoe.samples \
-DprojectArtifactId=my-sample-decision-service \
-DprojectVersion=1.0.0-SNAPSHOT \
-DplatformGroupId=io.quarkus.platform \
-DplatformArtifactId=quarkus-bom \
-DplatformVersion={QUARKUS_VERSION_SHORT} \
-Dextensions=kogito-quarkus,dmn,resteasy-reactive-jackson,quarkus-smallrye-openapi,quarkus-smallrye-health
+----

+[NOTE]
+====
+As you can see from the Maven command, there are a number of possible extensions that can be added to the project to add some sort of specific functionality.

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383066336:

+[INFO] Your new application has been created in /Users/developer/my-sample-decision-service
+[INFO] Navigate into this directory and launch your application with mvn quarkus:dev
+[INFO] Your application will be accessible on http://localhost:8080
+[INFO] ========================================================================================
+[INFO]
+[INFO] ------------------------------------------------------------------------
+[INFO] BUILD SUCCESS
+[INFO] ------------------------------------------------------------------------
+[INFO] Total time:  24.548 s
+[INFO] Finished at: 2022-09-27T10:22:31-04:00
+[INFO] ------------------------------------------------------------------------
+----

+[start=3]
+. Add the following properties to the pom.xml file, using the row numbers as a guide.
+This specifiies the Maven coordinates for the {PRODUCT_SHORT} Maven Bill-of-Materials (BOM), which manages all of the associated depenency versions to a specific {PRODUCT_SHORT} release:
typo
specifiies -> specifies

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383066793:

+[start=3]
+. Add the following properties to the pom.xml file, using the row numbers as a guide.
+This specifiies the Maven coordinates for the {PRODUCT_SHORT} Maven Bill-of-Materials (BOM), which manages all of the associated depenency versions to a specific {PRODUCT_SHORT} release:
+
+[source,xml,subs="attributes+"]
+----
+17        <surefire-plugin.version>{SUREFIRE_MAVEN_PLUGIN}</surefire-plugin.version>
+18  +++   <kogito.bom.group-id>com.ibm.bamoe</kogito.bom.group-id>
+19  +++   <kogito.bom.artifact-id>bamoe-bom</kogito.bom.artifact-id>
+20  +++   <kogito.bom.version>{BOM_VERSION}</kogito.bom.version>
+21
+----
+
+[start=4]
+. Replace lines 29-31, which is essentially just adding the bamoe-bom to the list of imported dependencies:
Remove 'just'

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383068336:

+30  +++   ${kogito.bom.artifact-id}
+31  +++   ${kogito.bom.version}
+32        pom
+33        import
+34
+----
++
+A bill of materials (BOM) is a list of the parts or components that are required to build a product.
+BOMs are ordinary pom.xml files — they contain no source code and their only purpose is to declare their bundled modules.

+.Always use the Maven Bill-of-Materials (BOM)
+[IMPORTANT]
+====
+It is highly recommended to use a bill of materials (BOM) to manage project depencencies, as it simplifies the dependency management by organizing a group of depdenencies under a single version.
+
+It must be noted that the use of Maven bill-of-materials (BOM) does not add any actual dependencies to the project, they are only definition that will help resolve properly (versions) the dependendies (and transient dependencies).
definition 'that will' help resolve -> definition that helps resolve
Typo in dependendies
-> dependencies

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383070315:

+A bill of materials (BOM) is a list of the parts or components that are required to build a product.
+BOMs are ordinary pom.xml files — they contain no source code and their only purpose is to declare their bundled modules.

+.Always use the Maven Bill-of-Materials (BOM)
+[IMPORTANT]
+====
+It is highly recommended to use a bill of materials (BOM) to manage project depencencies, as it simplifies the dependency management by organizing a group of depdenencies under a single version.
+
+It must be noted that the use of Maven bill-of-materials (BOM) does not add any actual dependencies to the project, they are only definition that will help resolve properly (versions) the dependendies (and transient dependencies).
+====
+
+A bill of materails (BOM) can be added to an existing POM file by adding it to the dependencyManagement section as a dependency with a pom type:
+
+include::../partials/maven-bom-now.adoc[]
+
+When a bill of materials (BOM) is used it is not necessary to specify the depenency's version, as that comes from the BOM, and hence your dependencies are viewed as follows:
comes -> appears

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383073920:

+When a bill of materials (BOM) is used it is not necessary to specify the depenency's version, as that comes from the BOM, and hence your dependencies are viewed as follows:
+
+[source,xml]
+----
+

   <groupId>org.drools</groupId>

   <artifactId>drools-compiler</artifactId>

+
+----
+
+[NOTE]
+====
+While updating your Maven dependency, you might encounter any dependencies that are 'not' included in the bill of materials (BOM), use the Maven library version noted in the table as follows:
Remove quotes around 'not'

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383078927:

+[NOTE]
+====
+You might notice that the newly added Maven dependency includes the groupId and artifactId portions of the Maven coordinates, but does not specifcy a version tag.
+This is due to importing the bamoe-bom into the project, where the various dependency versions are managed.
+====
+
+[start=6]
+. Build the project in the root folder:
++
+[source,console]
+----
+mvn clean package
+----
++
+You might get some Maven streaming text once again, and at the end of it you should have:
should - >must

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383080127:

+[INFO] Finished at: 2023-06-28T14:22:02-03:00
+[INFO] ------------------------------------------------------------------------
+----

+[NOTE]
+====
+The choice of extensions determines the imported behavior of the project, including adding sample models or testing related code.
+For example, by adding the 'dmn' extension not only adds the proper dependencies, but also adds a sample .dmn model to the project, which acts as a template to work from.
+====
+
+After the project has been generated, you must see a project structure in VS Code, similar to the following diagram:
+
+.Example Maven Project in VS Code
+image::maven-project.png[Example Maven Project in VS Code]
+
+As you can see from the figure above, a Maven compliant project is generated, including all of the standard folders typically found in a Maven project.
Remove 'above'

In migration-guide/now-to-next.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383082022:

+- Decision Model & Notation (DMN) Models (.dmn)
+- Drools Rule Language (DLR) Files (.drl)
+- Business Process Modeling & Notation (BPMN) Models (.bpmn)
+- Excel Decision Tables (XLS) Files (.xls)
+- Standard Property Files (.properties)
+- Test Scenario Files (.scesim)

+[NOTE]
+====
+The proper folder for unit test files is src/test/resources, since this is a testing resource.
+====
+
+=== Step 3: Add Business Automation Assets
+
+If your project is migrated from a previous version of the product, you can add the business automation files from that previous project to the src/main/resources folder of the new project by copying the file(s).
+If you want to create a new file, use VS Code's File : New File option, making sure to specify the file extension properly to associate the new file with the appropriate editor.
Remove 'properly'

In partials/quarkus-extensions.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383084259:

org.kie.kogito

kogito-quarkus-decisions
+
+----

+|===
+
+
+[TIP]
+====
+You can use the following link to obtain more information regarding the various https://quarkus.io/extensions/[Quarkus Extensions] availble to you.
+====
+
+[NOTE]
+====
+Some product dependencies, including extensions, may be renamed in the next release.
may -> can

In migration-guide/drl.adochttps://github.com/IBM/bamoe-docs/pull/52#discussion_r1383090282:

+end
+----

+The non-executable model coerces 10 to Long, so it doesn't throw an Exception.
+However, the executable model throws a build error: The method setWrapperLong(Long) in the type Fact is not applicable for the arguments (int).
+In this case, the rule can be easily fixed by using valid Java syntax. For example:
+
+[source.java]
+----
+...
+then

$f.setWrapperLong(10L);
+end
+----

+Generics return type resolution, assuming you have classes below:
Remove 'below'
assuming you have classes below -> assuming the existing following classes ?
—
Reply to this email directly, view it on GitHubhttps://github.com/IBM/bamoe-docs/pull/52#pullrequestreview-1714319757, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD7S3FLY6LAFFQR3JRDUGNLYDC6RZAVCNFSM6AAAAAA65VXAJWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTOMJUGMYTSNZVG4.
You are receiving this because you authored the thread.Message ID: @.***>

Closing this PR, @blulas will create a new PR with a clean history.


Once a community is private, should not be able to be converted back to public

PR https://github.com/OkunaOrg/okuna-api/pull/672


Add support for external keys and importing custom key material

This PR adds support for EXTERNAL origin keys and the ability of import custom key material.
One note of the implementation of the key material import process is that I have chosen the easy (lazy?) route of just attaching a single  ParametersForImport to an existing key. This means that multiple calls to GetParametersForImport will resulting in the older parameters being overwritten. Not sure if this differs from the AWS implementation or not. However this implementation does:

offer a simplistic way to test "expired/non-existent" import parameters as one can simply call the get parameters method twice
simplifies the implementation and reduces database size (over time) as we don't have to worry about cleaning up expired import parameters

Also, I haven't added any tests for this yet. I have looked at the Postman collection and am open to trying to add tests to this collection even if I'm not exactly sure how to generate the required input for ImportKeyMaterial (see bash script in README.md for what this looks like). However, when I did import the Postman collection it took me quite a while to get the existing test set running as it relies on a number of variables which seem to be stored in local environment rather than as part of the collection. Might be worth considering other options - native go tests? Am open to ideas/discussion here.

Thanks @onematchfox, I'll take a look at this asap this week.
And I agree the testing needs changing. Postman worked fine as a quick way of getting started, but it's not really conducive to multiple developers. I think perhaps it should be swapped out for something script based. I'd like to keep the tests functional based - i.e. testing from a HTTP perspective as I've built most of this with TDD; writing tests against AWS, then implementing LKMS to match. So native Go sounds a good option. Or Python with Requests perhaps.


Update code style reference to Black from PEP 8

Fixes #4409
(hopefully I'm not making a conflicting PR; feel free to close this if someone else is working on this)

@chfw We don't use white on this project, I don't see any reason a reference to add it here.


[Newsfeed] Getting a type error when using readUpdatableFragment for StoryLikeButton

I'm getting the following type error when following the guide here: https://relay.dev/docs/tutorial/mutations-updates/#step-3--call-readupdatablefragment
Argument of type 'StoryLikeButtonFragment$key' is not assignable to parameter of type 'Readonly<{ ' $data'?: unknown; $updatableFragmentSpreads: unknown; }>'.
  Property '$updatableFragmentSpreads' is missing in type 'StoryLikeButtonFragment$key' but required in type 'Readonly<{ ' $data'?: unknown; $updatableFragmentSpreads: unknown; }>'`

Here is the entire onLikeButtonClicked function:
const onLikeButtonClicked = () => {
    commitMutation({
      variables: {
        id: data.id,
        doesLike: !data.doesViewerLike,
      },
      optimisticUpdater: (store) => {
        const fragment = graphql`
          fragment StoryLikeButton_updatable on Story @updatable {
            likeCount
            doesViewerLike
          }
        `;
        const { updatableData } = store.readUpdatableFragment_EXPERIMENTAL(
          fragment,
          story
        );
        const alreadyLikes = updatableData.doesViewerLike;
        updatableData.doesViewerLike = !alreadyLikes;
        updatableData.likeCount += alreadyLikes ? -1 : 1;
      },
    });
  };

It might be helpful to put your code as a fork on github so that we can see the whole thing.

I am stuck at the same point.
When running store.readUpdatableFragment(fragment, story) as recommended in the tutorial, I receive a type error of Property 'readUpdatableFragment' does not exist on type 'RecordSourceSelectorProxy<{}>' and a console error (on clicking like button) of:
Warning: A store update was detected within another store update. Please make sure new store updates aren't being executed within an updater function for a different update.

When running store.readUpdatableFragment(fragment, story), as this method appears to be available according to type checking, I see the type error mentioned by @MrJackWilson and the following console error (on clicking like button):
Warning: RelayModernSelector: Expected object to contain data for fragment `StoryLikeButton_updatable`, got `{"title":"Local Yak Named Yak of the Year","summary":"The annual Yak of the Year awards ceremony took place last night, and this year's winner is none other than Max, a beloved yak from the small town of Millville. Max, who is known for his friendly personality and hardworking nature, beat out stiff competition from other yaks in the region to take home the coveted title.\n \nAccording to the judges, Max stood out due to his exceptional contributions to the community. He has been used as a pac…`. Make sure that the parent operation/fragment included fragment `...StoryLikeButton_updatable` without `@relay(mask: false)`.

Problem line in fork

The types forces me to use readUpdatableFragment_EXPERIMENTAL method instead of readUpdatableFragment, I'm able to call readUpdatableFragment though so this is an issue with types.
But I also get error during runtime:
Warning: A store update was detected within another store update. Please make sure new store updates aren't being executed within an updater function for a different update.

When I switch to _EXPERIMENTAL method I get error:
RelayModernSelector: Expected object to contain data for fragment `StoryLikeButton_updatable`, got `{"title":"Local Yak Named Yak of the Year","summary":"The annual Yak of the Year awards ceremony took place last night, and this year's winner is none other than Max, a beloved yak from the small town of Millville. Max, who is known for his friendly personality and hardworking nature, beat out stiff competition from other yaks in the region to take home the coveted title.\n \nAccording to the judges, Max stood out due to his exceptional contributions to the community. He has been used as a pac…`. Make sure that the parent operation/fragment included fragment `...StoryLikeButton_updatable` without `@relay(mask: false)`.

With Relay v16, The _EXPERIMENTAL is gone, so now we are left with the RelayModernSelector error happening with every use of readUpdatableFragment. The docs example (https://relay.dev/docs/tutorial/mutations-updates/#step-3--call-readupdatablefragment) is still producing the error too.

The only way I could make this work was by spreading the updatable fragment on the page query itself (looks like you cannot spread it on the component fragment?), and then doing some type-casting when running it, e.g:
        const fragment = graphql`
          fragment StoryLikeButton_updatable on Story @updatable {
            likeCount
            doesViewerLike
          }
        `;
        const { updatableData } = store.readUpdatableFragment<StoryLikeButton_updatable$key>(
          fragment,
          story as any
        );
        const alreadyLikes = updatableData.doesViewerLike;
        updatableData.doesViewerLike = !alreadyLikes;
        updatableData.likeCount += alreadyLikes ? -1 : 1;

Spreading the fragment on the query is what made the warnings go away, but I did not see this being mentioned in the page.
Spreading it on the fragment causes relay to throw an error saying the updatable fragment cannot be spread on the root.
I am still trying to figure out how to update non-scalar values tho, as it seems the TS generated setters do not include the nested fields of the linked record?


feat(dashboard): Dashboards backend implementation

Checklist

[X] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[X] Tests for the changes have been added/updated (if applicable)
[X] Docs related to the changes have been added/updated (if applicable)

@grantatspothero you may be interested in reviewing this.


UUID generator and SMS OTP generator needs to be Configurable

Issue
In the current implementation, the OTP generation is hardcoded. The OTP patterns generated in EMAIL OTP, UUID, SMS OTP are hardcoded at the movement.
Requirement

[ ] Make the OTP patterns configurable by the Identity admin.
[ ] Make to UUID generator and SMS OTP generator extended : https://github.com/wso2/product-is/issues/6446

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


WebApp:staticwebapp - add command to update a static web app

Describe the solution you'd like
This enables changing settings on the Static Web App, including its plan.
Additional context
Required for Static Web Apps GA.

We will check and consider it for future milestone.

@panchagnula FYI


Errors when running downsample_logging.py

Hi,
I followed the ReadMe and recording start but shortly after the follow errors start to occur repeatedly.
I am running a JS110
Any thoughts ?
Thanks
2023-09-15T13:48:26 ERROR    status returned 11
2023-09-15T13:48:28 WARNING  ctrl_in timed out
2023-09-15T13:48:28 ERROR    status returned 11
2023-09-15T13:48:31 WARNING  ctrl_in timed out
2023-09-15T13:48:31 ERROR    status returned 11
2023-09-15T13:48:34 ERROR    handle_rsp unsupported !ctrl_in
2023-09-15T13:48:35 WARNING  ctrl_in timed out
2023-09-15T13:48:35 ERROR    status returned 11
2023-09-15T13:48:35 ERROR    handle_rsp unsupported !ctrl_in
2023-09-15T13:48:36 WARNING  ctrl_in timed out
2023-09-15T13:48:36 ERROR    status returned 11
2023-09-15T13:48:36 ERROR    handle_rsp unsupported !ctrl_in
2023-09-15T13:48:38 WARNING  ctrl_in timed out
2023-09-15T13:48:38 ERROR    status returned 11
2023-09-15T13:48:39 WARNING  ctrl_in timed out

Those messages indicate that your JS110 is not correctly communicating with the host.  A few questions:

What host OS and computer are you using?
Is the JS110 connected directly to a USB port on the host computer, no hubs, docks or adapters?
Does this same setup work with the Joulescope UI?

Hi,

Its Mac M1 running OSX Venutra.
The JS110 goes via an Apple USB to USB-C converter but thats it.
Joulscope UI seems to work fine.
Python 3.11.3 (main, Jun  5 2023, 13:12:00) [Clang 14.0.3 (clang-14<IP_ADDRESS>.1)]

Thanks,
Serge

Ok, macOS does some annoying power management that may prevent this script (and all others) from working.
Do you care about standard deviation?  If not, you can also try using on-instrument 2 Hz statistics.  Add the --source sensor command line argument to downsample_logging.py.
In the Joulescope UI, we use appnope to prevent macOS from performing app nap.  You could modify downsample_logging to have this.  First, pip install appnope.  Then just insert this near the top of downsample_logging.py:
import appnope
appnope.nope()

Does this help?

Hi,
Neither option resolves the issue.
Thanks,
Serge

Ok, so I am not sure what is happening yet.  Let's try a few other things:

Is your mac plugged into power?
Do both the sensor-side LED under "IN" and the host-side "Status" LED remain illuminated when this occurs?
Does this command work: python -m pyjoulescope_driver statistics

Ok.  I do not understand what is happening with downsample_logging.py on your machine.  I just tried this on a MacBook POro 13-inch 2020 M1 running macOS 13.4.1 (c) with python 3.11.5.  It has been running over 5 minutes.  I will keep it running and let you know if I see anything.
Are you running brew?  You can update everything: brew update && brew upgrade
You can also ensure that the python packages are up to date: pip install -U --upgrade strategy eager joulescope
Does running python -m pyjoulescope_driver statistics get you what you need?

OK thanks, I changed the USB adapter but that did not help nor did the upgrades. I am still going to try a different USB cable.

I dont know, I have to read-up and see what it does.

Thanks

I saw that I had a macOS update.  I updated to macOS 13.5.2, but downsample_logging.py still works for me.
However, I noticed a few log messages that I think indicates that the JS110 is still streaming samples even with the --source sensor argument.  It should not be, which significantly reduces the data rate and chance for errors.  If you only need statistics data from a single JS110 source, then python -m pyjoulescope_driver statistics is a great choice.

Hi.
Did this ever get fixed ?
However, I noticed a few log messages that I think indicates that the JS110 is still streaming samples even with the --source sensor argument
I am still unable to use downsample_logging.py
Thanks,
Serge

Hi @ssozonoff  - We did no further investigation since we could not duplicate the issue and you seemed to be OK.
We will try to duplicate this again.
To confirm. is this the command you are having trouble with?
python3 downsample_logging.py --source sensor

Hi.That’s correct.  I have tried another USB cable, USB port and even an adapter but still getting the error.Thanks,Serge Sent from my iPhone 6On 5 Mar 2024, at 21:34, Matt Liberty @.***> wrote:
Hi @ssozonoff  - We did no further investigation since we could not duplicate the issue and you seemed to be OK.
We will try to duplicate this again.
To confirm. is this the command you are having trouble with?
python3 downsample_logging.py --source sensor
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Hi @ssozonoff
There are really two problems here:

Your MacBook does not support JS110 sample streaming.
The downsample_logging.py script causes JS110 sample streaming, even with --source sensor.  I confirmed the sample streaming using a TotalPhase Beagle USB 5000.

I suspect that MacBook power management is causing (1).  However, we have not proven this.  Looking at the conversation above, I see that appnope did not solve the problem.
If we could fix (2), then (1) becomes less of an issue for the moment.  I took a closer look at downsample_logging.py.  While it still works, it was also the first script we wrote after launching the JS110.  Since the focus of this script is reliability, it really should now directly use pyjoulescope_driver and avoid the additional complexity of the joulescope package.  I have made these changes.
Can you please try out the latest downsample_logging.py script?
Does this updated script now work for you?

Hi Matt,
I tested the modified downsample_logging.py script you provided and it works fine. Thanks for porting it to use pyjoulescope_driver.
Kind regards,
Serge


add date of birth using the corrections endpoint if required

Epic requires all accounts to have a date of birth set and prevents logging in if you don't have it.

This PR handles this by setting the birthday to a random date between 1995 and 2003 if this is the case for an account.

Thanks for the PR. The fix is now available on pypi :)


Enable ephemeral compression levels

This adds temporary settings to ImfHeader to control the compression levels used.

NB: This does change the ABI of the Header class, as well as the internal compression classes (although those matter less) so should not be merged into 3.1.
When reviewing, I did run clang-format on these files.
@aras-p This is the proposal for the temporary settings I mentioned in #1125. I have NOT changed the default value yet. If / once this is accepted, please submit a PR to change to your suggested new default of 4, such that you get the proper credit due for testing all this

If / once this is accepted, please submit a PR to change to your suggested new default of 4

Cool, will do!
The formatting of touched files makes this PR look larger than it actually is. On the other hand, looks like you found that e.g. _readsNothing used to not be quite initialized, so 🎉

This is confusing to read. Can I suggest that you first make a separate PR with just the clang-format changes? Format changes should always stand alone (and their commits can be listed in .git-blame-ignore-revs).
Then on top of that, a separate PR can implement the compression changes and be smaller and easier to read.
Can you clarify the current plan about how to implement the parts of Aras's compression suggestions? I agree that eventually we want to be able to specify compression per-file, but it seems like this solution at least changes ABI, which means it's a minimum of 3.2 (or is it 4.0? will it require changes to client source code?). Because VFX Platform will only allow binary-compatible upgrades during the year, that means the BIG WIN of compression changes won't hit most users until 2023, which seems to me like a real missed opportunity to get a great performance improvement across many applications.
Might we consider a "global" setting for default compression and a standalone function to set it (a little like how thread pool size is done now)? This would not allow the fine-grained per-file control, but it would be binary compatible and thus backportable to a 3.1 patch immediately, and probably is the only granularity of control that most applications need.
Note that this is very different from the dwa compression settings, which must be per-file because they affect image quality as well as size -- there is no one correct setting. But the zip compression level is lossless either way, it's purely a size-vs-time tradeoff, and I suspect that unless there is a problem with Aras's testing methodology, we'll end up changing the default to the new way and the only people who want the control at all will be those who have testing/validation situations where they must produce files that are bit-for-bit identical with saved reference images.

Yeah, I accidentally hit clang-format in the middle of making the changes. I had thought we had actually run it on the whole repo, but I guess not :( Let me remake w/o that, you're right, it will be cleaner.

So yes, this does change the ABI, in that the layout for ImfHeader is changing - the changes to the compression objects are internal, and not exported, so would be fine. I guess I am already in the mode that I am going to start changing the c++ ABI fairly dramatically soon, but your point about it then not getting deployed for a while is quite valid...
I did briefly consider hiding the values for the compression in the attribute map, using the empty string as the key, which is an invalid attribute name as far as the rest of the system is concerned, so should never conflict. However, that seemed like it might be "too" clever. That would give us per-part control over this, which might be interesting to see if different AOVs we can actually push further.
So we could do that if you'd prefer, I can write that up and change the above to that to see if you'd prefer that. That would eliminate the external ABI change, and we are only adding non-virtual functions, which would be the same as if we added global functions, so technically are safe to do so to get this in sooner. I don't really like global functions / values because it seems like a bodge, and inconsistent w/ the way the dwaCompression works, which also uses zipCompression for some modes, so it seems like they should be consistently edited, but maybe that's just me

Actually, strike the empty string in the map - I forgot about the iterators we provide, that would be confusing to people. If we all agree we would like to set it on a per-part basis (I am asking - I think that is what feels right to me), like the dwa compression, we could add that api (not abi breaking), but instead of storing the values in the header, we could store them internally to the library when not default, allowing us to undo the abi breakage so we could put this into 3.1

I'm not against any of the flexibility eventually. I just plead for a way to unlock the write speed improvement for 3.1 users in 2022.
Though I definitely see wanting to set the compression method -- including the quality level of a lossy codec -- separately per part (that is, per AOV or type of data), I'm not sure that there is a real-world use case for setting the runtime choice of lossless compression differently per part. I'm not even confident people will want it different per file. My intuition is that an entire app/studio will make the decision "let's sacrifice 1% disk space for 2x write speed" across the board. But I do know that they want it to be a runtime option, not a build time option, because (a) it makes comparison testing easier to not need separate builds, and (b) many users are stuck with the compiled library that their studio/distro/DCC gives them and don't have the freedom to rebuild from source to enable a big speedup.

I've added an internal stash such that the ABI does not have to change to enable this. I ran abi-compliance-checker against the OpenEXR libraries on my system (not compiled by me), and it finds that I've added some functions, but is otherwise clean. It would be good if someone else could validate that as well, although I believe I did the right tests, as when I compare against current master, it correctly identifies the oss fuzz api difference as a problem

Further to @lgritz request, I have made the global default accessible. This way you can set the global default at runtime as well as compiling it in, but the setting in the header will still allow one to control it on a per-part basis as desired

ImfStandardAttributes.cpp:55:41: warning: 'const OpenEXR_3_1_sidefx::TypedAttribute<float>& OpenEXR_3_1_sidefx::dwaCompressionLevelAttribute(const OpenEXR_3_1_sidefx::Header&)' is deprecated: use compression method in ImfHeader [-Wdeprecated-declarations]
   55 |         return IMF_NAME_ATTRIBUTE(name) (header).value();           \
      |                                         ^
ImfStandardAttributes.cpp:99:1: note: in expansion of macro 'IMF_STD_ATTRIBUTE_IMP'
   99 | IMF_STD_ATTRIBUTE_IMP (dwaCompressionLevel, DwaCompressionLevel, float)
      | ^~~~~~~~~~~~~~~~~~~~~
In file included from ImfStandardAttributes.cpp:12:
ImfStandardAttributes.cpp:99:24: note: declared here
   99 | IMF_STD_ATTRIBUTE_IMP (dwaCompressionLevel, DwaCompressionLevel, float)
      |                        ^~~~~~~~~~~~~~~~~~~
ImfStandardAttributes.h:46:34: note: in definition of macro 'IMF_NAME_ATTRIBUTE'
   46 | #define IMF_NAME_ATTRIBUTE(name) name##Attribute
      |                                  ^~~~
ImfStandardAttributes.cpp:99:1: note: in expansion of macro 'IMF_STD_ATTRIBUTE_IMP'
   99 | IMF_STD_ATTRIBUTE_IMP (dwaCompressionLevel, DwaCompressionLevel, float)
      | ^~~~~~~~~~~~~~~~~~~~~


Updating Manufacturing solutions page

Description
Can you please add a resources section to the bottom of the page along with the CTAs to try/install FlowFuse?
We can list the following:
https://flowfuse.com/customer-stories/leveraging-node-red-and-flowfuse-to-automate-precision-manufacturing/
https://flowfuse.com/customer-stories/stfi-future-of-textile-powered-by-node-red/
https://flowfuse.com/customer-stories/manufacturing-digital-transformation/
https://flowfuse.com/blog/2023/10/citizen-development/
Epic/Story
No response
Have you provided an initial effort estimate for this issue?
I have provided an initial effort estimate

Hi @Hasmin-AC check out this mock up, I this what you had in mind? (The articles are not the ones on the list, I took them from another page to demonstrate the layout).

Yes this can work, but can we add short descriptions to the resource boxes?
Also lets take off the sub header in the deployment section. For the CTA's there, Cloud should be "Sign up", and Self managed should go to "Install".
Thanks!

can we add short descriptions to the resource boxes
We can, for the blog post I can take the description from the front matter, but the customer stories don't have descriptions, could you please provide them? A really short text would be the best.
This is how it currently looks, only with the titles and I think it already looks kind of crowded (I haven't updated the images)

Would the Images have the title of the content? If thats the case i can provide a description (let me know character limit) and we have only description as text and the title in image.

Would the Images have the title of the content?

Only the blog post has the image with title, the customer stories are photos or graphics with no text.

OK. Then for the case studies, we'll stick to title only but precede with "Case Study: "
For blog since the title will be on the image, lets add the short description as text.


integration: fix go vet -shadow error

breaking go tip

lgtm

ci failed with
gopath/src/github.com/coreos/etcd/integration/v3_watch_test.go:191: no new variables on left side of :=


Ability to have get current state of FutureProvider as if it were an object/manipulatable data

In Riverpod, you're able to create a FutureProvider as shown:
final helloWorldProvider = FutureProvider<String>((ref) async {
  await Future.delayed(Duration(seconds: 3));
  return "Hello world";
});

In Riverpod 2.0+ or Riverpod Generator, one can achieve this simply by using:
@riverpod
Future<String> helloWorld(HelloWorldRef ref) async {
  await Future.delayed(Duration(seconds: 3));
  return "Hello world";
}

// Or you can do something like this:

@riverpod
class HelloWorld extends _$HelloWorld{
  FutureOr<String> build() async {
    await Future.delayed(Duration(seconds: 3));
    return "Hello world";
  }
}

However, in these examples, when using the provider, you always have to obtain its current state with the .when(...) function. After running it once, it should be able to return its current state without having to run the entire future again, and if I haven't run it once, it should be able to return null. Ex:
ref.watch(helloWorldProvider).currentState; // null

ref.watch(helloWorldProvider).when(...)

// Somewhere else in the UI
ref.watch(helloWorldProvider).currentState; // "Hello World"

// Does not enable a refresh
ref.watch(helloWorldProvider).currentState = "Hello Riverpod";

ref.watch(helloWorldProvider).currentState; // "Hello Riverpod"

So effectively it should have the same capability as a StateProvider where the user can access the current state of it and manipulate it.
@riverpod
class HelloWorld extends _$HelloWorld{
  String build() {
    return "Hello World";
  }
}

ref.watch(helloWorldProvider); // Hello World

One thing I tried was using both a NotifierProvider and an AsyncNotifierProvider (In Riverpod 2.0 & Generator, however, this is also equivalent to using a StateNotifierProvider and a FutureProvider). In the following example I get an error saying that the value returned must be of type String and not AsyncValue.
@riverpod
class HelloWorld extends _$HelloWorld{
  FutureOr<String> build() async {
    await Future.delayed(Duration(seconds: 3));
    return "Hello World";
  }

  String getHelloWorld() {
    return state; // Returns exception because the function's return type is String but the state is equal to AsyncValue.
  }
}

Because of this I end up writing lengthier files and find myself passing objects between Widgets because I cannot access them directly through the provider. For example: If I wanted to use my hello world provider on both screen 1 and 2, I would have to pass my string into the second screen after I obtain it from the first screen in a .when(...) function. However, when doing this with a StateProvider or NotifierProvider, you don't have to pass in the state at all, but instead you can simply call: ref.watch(helloWorldProvider).
A current workaround for this was provided by Adnan on Stackoverflow which uses a StateProvider in addition to the FutureProvider and uses Future.microtask(...) to set the value of the StateProvider in the .when(...) function. Ex from Stackoverflow:
// this will obtain the future/initial value
final _futureCounterProv = FutureProvider(
  (ref) async {
    Future.delayed(
      Duration(seconds: 3),
    );
    return Random().nextInt(100);
  },
);

// this provider will provide the current value of the counter
final _counterProv = StateProvider((ref) => 0);

class Body extends ConsumerWidget {
  const Body({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    return ref.watch(_futureCounterProv).when(
      loading: () {
        return const Center(
          child: CircularProgressIndicator(),
        );
      },
      error: (error, stackTrace) {
        return Text(error.toString());
      },
      data: (data) {
        Future.microtask(
          () {
            // Assigning the future value to the `StateProvider`
            return ref.read(_counterProv.notifier).state = data;
          },
        );
        return Consumer(
          builder: (context, ref, _) {
            final count = ref.watch(_counterProv);

            return Column(
              children: [
                IconButton(
                  onPressed: () {
                    ref
                        .read(_counterProv.notifier)
                        .update((value) => value + 1);
                  },
                  icon: const Icon(Icons.add),
                ),
                Text(
                  count.toString(),
                ),
              ],
            );
          },
        );
      },
    );
  }
}

If you do not use Future.microtask(...) then you will get an exception saying that you tried to change the state of a provider as it was building inside of the build() or initState() or didUpdate() etc.

Hello!
Are you looking for AsyncValue.requireValue?
FutureProvider<String> provider

build(context, ref) {
  String value = ref.watch(provider).requireValue;
}

Thanks for this. This solves the issue of retrieving the value, but I'm still not able to set the value like how you can set the NotifierProvider state. Will there be functionality for this in the future?

With an AsyncProvider, I don't believe there is the ability to set the state of it the same way you can with a StateProvider/NotifierProvider, unless I'm understanding it wrong. Should I continue using the workaround or, if you can, please provide and example of how to do this.

You can freely call state = AsyncValue.data(newState) in AsyncNotifier

I was a part of the conversation on stackoverflow that led to opening this issue.
After a small demo, I found out that AsyncNotifier actually solves this.
In my case, I had a list screen where elements had ids related to other entities. In order to build the update form I needed to use the data already in hand and fetch the other entities from the server.
a simple example that uses AsyncNotifier to achieve this functionality:
(initializing the app)
import 'dart:async';

import 'package:flutter/material.dart';
import 'package:flutter_riverpod/flutter_riverpod.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const ProviderScope(
      child: MaterialApp(
        home: MyHomePage(),
      ),
    );
  }
}

the provider code
class Foo {
  // sync
  final int bar;
  // async
  int? baz;

  Foo(
    this.bar, {
    this.baz,
  });
}

Future<int> getBaz() async {
  return Future.value(1);
}

class FooController extends AsyncNotifier<Foo> {
  Foo foo;
  FooController(this.foo);

  @override
  FutureOr<Foo> build() async {
    foo.baz ??= await getBaz();
    return foo;
  }
}

final fooProv = AsyncNotifierProvider<FooController, Foo>(
  () => FooController(Foo(0)),
);

consuming the data
class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: Consumer(
        builder: (context, ref, _) {
          final fooAsync = ref.watch(fooProv);

          return fooAsync.when(
            data: (foo) => Text('bar: ${foo.bar}, baz: ${foo.baz}'),
            loading: () => const CircularProgressIndicator(),
            error: (err, stack) => Text(err.toString()),
          );
        },
      ),
    );
  }
}

Can confirm that this implementation works. I believe the documentation for this should be a bit more clear, as I couldn't find any guides or ways to achieve this especially for Riverpod 2.0 + Generator. I may add a guide to my blog on how to achieve this and how to use Riverpod 2.0 + Generator, as it will eventually be the standard.
I reconstructed @adnanjpg's script so hopefully this can get added.
Running the app:
main.dart
void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  @override
  Widget build(BuildContext context) {
    return const ProviderScope(
      child: MaterialApp(
        home: MyHomePage(),
      ),
    );
  }
}

Creating the foo class and provider:
foo.dart
part 'foo.g.dart';

class Foo {
  final int bar;
  int? baz;

  Foo(
    this.bar, {
    this.baz,
  });
}

@riverpod
class FooController extends _$FooController {
  FooController(this.foo);

  Foo foo;

  @override
  FutureOr<Foo> build() async {
    foo = await getFoo();
    return foo;
  }

  Future<Foo> getFoo() async {
    await Future.delayed(const Duration(seconds: 1));
    return Foo(1);
  }
}

Implementation using Async capabilities:
home.dart
class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: Consumer(
        builder: (context, ref, _) {
          // Get the provider and watch it
          final fooAsync = ref.watch(fooControllerProvider);

          // Use .when to render UI from future
          return fooAsync.when(
            data: (foo) => Text('bar: ${foo.bar}, baz: ${foo.baz}'),
            loading: () => const CircularProgressIndicator(),
            error: (err, stack) => Text(err.toString()),
          );
        },
      ),
    );
  }
}

Implementation using Notifier capabilities:
home.dart
class MyHomePage extends StatelessWidget {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(),
      body: Consumer(
        builder: (context, ref, _) {
          // Get Foo provider and set the state of it.
          // Use it as if it were a State Provider.
          ref.watch(fooControllerProvider.notifier).foo = Foo(3);

          // Use Foo in UI
          final foo = ref.watch(fooControllerProvider.notifier).foo!;
          // Use .when to render UI from future
          return Text('bar: ${foo.bar}, baz: ${foo.baz}');
        },
      ),
    );
  }
}

I do also recall having to update the foo.g.dart file to accommodate for the generated provider:
final fooControllerProvider = AutoDisposeAsyncNotifierProvider<FooController, Foo>(
  () => FooController(Foo(1)),
  name: r'fooControllerProvider',
  debugGetCreateSourceHash: const bool.fromEnvironment('dart.vm.product') ? null : $FooControllerHash,
);

I've updated the answer on stackoverflow to include the latest result we've came up with.

is possible if we have stored data or something data into riverpod ? because when i used stateprovider. there's not i'm found a option to write a new data. thx u in advance

@michaelsof47 the problem is not really understandable from what you've said. please provide more details and provide a code example if possible

ouwhh, i see.. so, i think to give a example...
Page1.class
`
class Page1 extends ConsumerStatefulWidget {
@override
ConsumerState createState() => Page1State();
}
class Page1State extends ConsumerState {
…
@override
void initState() {
super.initState();
ref.read(_argumentsData.notifier).state = “Done”;
}
…
}`
also, i create a custom provider class that use as bridge between two class
final _argumentsData = StateProvider<String>((ref) => “”);
and at page 2 class, i have called data like this
`class Page2 extends ConsumerStatefulWidget {
@override
ConsumerState createState() => Page2State();
}
class Page2State extends ConsumerState {
…
@override
void initState() {
super.initState();
var value = ref.watch(_argumentsData);
print(value);
}
…
}`
but, when i try with this step. it give me error like this :
The following assertion was thrown building Builder:
dependOnInheritedWidgetOfExactType() or dependOnInheritedElement() was
called before VerifyOTPPageState.initState() completed.
When an inherited widget changes, for example if the value of Theme.of() changes, its dependent
widgets are rebuilt. If the dependent widget's reference to the inherited widget is in a constructor
or an initState() method, then the rebuilt dependent widget will not reflect the changes in the
inherited widget.
Typically references to inherited widgets should occur in widget build() methods. Alternatively,
initialization based on inherited widgets can be placed in the didChangeDependencies method, which
is called after initState and whenever the dependencies change thereafter.

it is not healthy to be updating a StateProvider's state in initState, in the example you have provided it is not clear why you have the need to update the state inside initState, I need a more real example to understand why you need to do this, and if there's a more stable way to do this


Added documentation for api-version 2023-11-15 which adds physicalZone

This PR focuses on updating the IMDS docs by adding the new available api-version "2023-11-15". This new version of IMDS will return a new value, physicalZone, that describes the physical location of the VM.

@KumariSupriya
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Blue highlights on interaction (Mobile)

https://github.com/themesberg/flowbite-vue/assets/47904282/80c996a4-fe81-4356-9e3c-339a0bd5cf73

I would like to tackle this issue :)


Support bz2 source archive

Is your feature request related to a problem? Please describe.
Have an Opam file depend on ocaml-version.3.7.1 (https://opam.ocaml.org/packages/ocaml-version/ocaml-version.3.7.1/).
opam-nix crashes with this error:
Running phase: unpackPhase
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking source archive /nix/store/hk2v8584dqhsa6vb9d624zzmwka1vbvi-ocaml-version-3.7.1.bz2
do not know how to unpack source archive /nix/store/hk2v8584dqhsa6vb9d624zzmwka1vbvi-ocaml-version-3.7.1.bz2

Describe the solution you'd like
Support .bz2 source archive formats.
Describe alternatives you've considered
N/A.
Additional context
N/A.

Can you check if it works with d464d52 ?

I couldn't directly check with this commit because of https://github.com/tweag/opam-nix/issues/99 but I tried by cherry-picking https://github.com/tweag/opam-nix/commit/d464d52bdb879c4e943c8ac5f20e01465d6fdfd5 on top of main: https://github.com/sir4ur0n/opam-nix/commit/1ef3623fd23a06e37fbb4cae41971d7d880b1953
The error is the same:
error: builder for '/nix/store/28wf7i3bfmw0cwqv5h1wknsgbs7hxbkg-ocaml-version-3.7.1.drv' failed with exit code 1;
       last 3 log lines:
       > Running phase: unpackPhase
       > unpacking source archive /nix/store/hk2v8584dqhsa6vb9d624zzmwka1vbvi-ocaml-version-3.7.1.bz2
       > do not know how to unpack source archive /nix/store/hk2v8584dqhsa6vb9d624zzmwka1vbvi-ocaml-version-3.7.1.bz2
       For full logs, run 'nix log /nix/store/28wf7i3bfmw0cwqv5h1wknsgbs7hxbkg-ocaml-version-3.7.1.drv'.
error: 1 dependencies of derivation '/nix/store/nrk07mq50pmqxjq33sq2mfhk6q5b070i-mdx-2.4.1.drv' failed to build
error (ignored): error: cannot unlink '"/tmp/nix-build-re-1.12.0.drv-2/build/re-1.12.0/_build"': Directory not empty
error: 1 dependencies of derivation '/nix/store/jgc60rcfc881qd8inkdy6lspc5n02zlb-nix-shell-env.drv' failed to build

Took some time to debug it, found the proper solution. ocaml-version-3.7.1 builds now.

I confirm it works with the latest commit on main, thank you :pray:


improvementUse count as ndv for unique/agg olap table single key column (#27186)

Single key column of unique/agg olap table has the same value of count and ndv, for this kind of column, don't need to calculate ndv, simply use count as ndv.
backport https://github.com/apache/doris/pull/27186
Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall