D10.3.1 on decimal field with precision 20 no check appears

@maxilein thanks for logging this. How can I reproduce this issue so I can create a patch?

That is a good question.

Are you sure that it works on D10.3.1? It is closer to D11 than D10.2 and older.

@mwebaze I've fixed the issue, now this module is working in Drupal 10.3

Please check the MR & Test it...

Thank you the buttons appear. And it seems to work, but for some reason there is a limit.

I have also posted a question regarding decimal field length here https://www.drupal.org/project/drupal/issues/2230909#comment-15680705 🐛 Simple decimals fail to pass validation Needs work

@maxilein and @Sourav_Paul, I have merged your request and pushed to dev. I have also added a core requirement on ^10.3.0 and hence removing support for 8, 9 and anything below 10.3. Do test and let me know so I can create a new release. Thanks for catching this.

If you mistakenly reduce precision of a field all data of it are lost.

Then there is something strange going on with the scale. But I am not sure if it is related to this module at all.
I will try to find out.

Forget #12. It is related to the precision handling of the other issue mentioned in#8

Increasing the precision of a field works!

So only #11 could have a warning or just don't do anything if the precision is reduced.

@maxilein when I increase or reduce the precision, the data value remains the same on my end. I cannot seem to reproduce #11

Ok. I will test again to get more info. But only in a couple of days.

@maxilein I also can't reproduce this issue by reducing or increasing the precision limit...

I suspect it was an edge case: I had a field with precision 20/2 while php precision was operating with 14
or a field with 20/2 with a php precision of 24.
The only thing I can think of that the deviation of default php precision and field max precision causes a failure.

@maxilein that is an interesting edge case. What we can do as you had earlier mentioned is notifier users of potential of loss when changed from high to low. What do you think?

Well maybe you check if php default precision set in php.ini differs from the field precision a warning could be useful.
Just give me a couple of days. I will test more to define the edge case better.

Your module is very important to any site builder in my opinion. So we should get that right.

I totally agree. Do go ahead and define the edge case better and I will put in some time to implement that.

@maxilein Are you defining the edge cases?

Yes. But give me some time please.

Ok. I tested various changes on field precision. But I could not reproduce the error.
Here is what I did:

1.)
php default precision (php.ini): 14
field (f) with precision: 20/2

Changing with precsion modifier:
setting f to 14/0 -> changes nothing and gives warning: Precision must be lower than or equal to 14.
setting f to 14/2 -> changes nothing and gives warning: Precision must be lower than or equal to 14.
setting f to 24/2 -> changes nothing and gives warning: Precision must be lower than or equal to 14.

looks ok.

2.) increasing php default to 32, rebooting.

php: 32
f: 20/2

setting f to 24/2 -> works
setting f to 32/2 -> works
reducing it back to 20/2 -> works.

So I think we can clear these cases.

Reducing the precsion of the field f down to 10 which is lower than some existing field values gives an error:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[22003]: Numeric value out of range: 1264 Out of range value for column 'field_largevalue_value' at row 15: INSERT INTO "node_revision__field_largevalue" ("bundle", "deleted", "entity_id", "revision_id", "langcode", "delta", "field_largevalue_value") VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, .....

Drupal\Core\Database\StatementWrapperIterator->execute() (Line: 44)
Drupal\mysql\Driver\Database\mysql\Insert->execute() (Line: 85)
Drupal\precision_modifier\services\PrecisionModifierService->increasePrecision() (Line: 84)
precision_modifier_field_storage_config_edit_form()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult() (Line: 39)
Drupal\layout_builder\Controller\LayoutBuilderHtmlEntityFormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 32)
Drupal\big_pipe\StackMiddleware\ContentLength->handle() (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

@mwebaze Can you look into this, Is there anything needed?

Here is an idea:

IF the code runs into errors because of numbers too large for the required precision:
It would be great if the code does not do all nodes at once and fails at the first .. so we don't know how many more times it would fail... making it a tedious taks to migrate precision affected data.

From a migration handling point of view:

It would be great to first get a number of nodes affected by that problem.

Let's say it reports: 12 nodes contain numbers larger than precision x.
Do you want to continue and delete those 12 values (The node ID and the dropped value will be logged)? Or Abort?

Then the user get's an option what to do.

At the end the output should be a list of nodes and values:
Values of the following nodes were dropped because the new precision is too small for the existing values:
The logged output after the new precision was set (and 12 values dropped) is a list like this:

Node ID | Title (as link to the node)| Dropped value as string |

123 "Some node title" "Original value: 123.123.123.123.123,34"
122 "Some node title" "Original value: 234.123.123.123.123,34"
...

So then by the migration no information is lost. It is completely transparent what happened. And one can use the old information in any way necessary.

@maxilein wouldn't it be much easier if I added a warning notifying of potential loss or precision or even data? Another idea borrowing from what you discussed is probably to create a restore point for the different nodes and field. One can then revert back to the previous value in-case if they want to.

You are right. It would be easier.
You could also use a view to find the values that are too large beforehand...

@mwebaze are you working on it?

@sourav_paul I haven't started working on that yet. I will start work on it next week.

@mwebaze are you still working on that?

Hi, I've applied the provided MR as a patch on 8.x-1.1 and it applied cleanly with no errors. On applying the issue of Precision increment for Integers and decimals. field not being shown while saving the field configuration has been resolved successfully. Now the precision field configuration is appearing and I'm able to save the precision configuration for the field and confirm that the issue has been resolved and the module's functionality is working fine. I'm attaching the before and after screenshots for reference.

The provided MR has already merged and it is resolving the issue. In addition, the new release of the module has already been released, can we mark the issue as Fixed.

@sourav_paul I haven't really started working on this as it is requested feature.
@tirupati_singh thanks for putting time into this. I will merge #33 but first I need to recreate the issue on my end.