Purchase Float

[justinkekeocha]

I can't find a way to make purchase for float amount in the documentation. when I try, it stores only Int amount in database

[rez1dent3]

Hello. Only the whole amount is always stored in the database. If you call the *float method, then the number calculated using the formula is saved to the database: amount * 10^decimal_places.

Let decimal_places =2. That is, you enter 100 into the depositFloat() method, but 100*10^2 (=10000) will be saved into the database.

Purchases operate under a strict contract. I did not want to divide them into two contracts (integers and fractions), but left only integers. The functionality, according to my analytics, is not very popular. It is used at first by startups, and later they implement their more complex functionality as part of the package.

I deliberately do not complicate the payment functionality with unnecessary functionality, because everyone needs different functionality and it is difficult to do something completely general.

If you have any ideas, I don't mind listening to them.

[justinkekeocha]

Thank you for your reply. Which float method are you referring to? I can't find float method for purchase. only for deposit, withdraw and the rest under the HasWalletFloat trait.

I am talking of purchases. Not regular depositFloat and Withdraw

[rez1dent3]

You understand that the cost will depend on the specific wallet and its decimal_places?

As I wrote above #775 (comment). No, the product contract obliges you to work exclusively with integers. I did not split it into two, so as not to overcomplicate the already complex logic of the package.

[justinkekeocha]

I also noticed that the paid method is deprecated in CartPay trait. Is there a new way to check if user have paid?
Or this is should be business logic too?

[rez1dent3]

    /**
     * Checks acquired product your wallet.
     *
     * @deprecated The method is slow and will be removed in the future
     * @see PurchaseServiceInterface
     */

Yes, it is enough to use PurchaseServiceInterface.

The code inside the paid method is up-to-date and can be used in your projects.

But in the standard implementation everything is done in a general form; for each project it is better to implement its own class from the PurchaseServiceInterface interface.

[justinkekeocha]

Check out this package https://github.com/stephenjude/laravel-wallet. It has only one method that handles integer and float.
Since all numbers are converted to an Integer when being stored to database. whether it was used by depositFloat or just deposit.

If the deposit method handles float number by defualt, the purchase functionality wouldn't need two contracts.

If deposit, is written as :

` public function deposit(int|string $amount, ?array $meta = null, bool $confirmed = true): Transaction
{
$math = app(MathServiceInterface::class);
$decimalPlacesValue = app(CastServiceInterface::class)->getWallet($this)->decimal_places;
$decimalPlaces = $math->powTen($decimalPlacesValue);
$amount = $math->round($math->mul($amount, $decimalPlaces, $decimalPlacesValue));

    return app(AtomicServiceInterface::class)->block(
        $this,
        fn () => app(TransactionServiceInterface::class)
            ->makeOne($this, Transaction::TYPE_DEPOSIT, $amount, $meta, $confirmed)
    );
}`

I want to know the possible implications. Will values be lost as you previous showed me in your previous example in the other discussion.

I have tried using depositFloat for integers, and it worked perfectly well. I don't see why this isn't the default mode for the deposit method.

I am sorry I am asking too many questions and I appreciate the time you take to answer questions

[rez1dent3]

You don't implement N-decimal_places in a simple implementation.

laravel-wallet/tests/Units/Domain/WalletFloatTest.php

Lines 276 to 281 in a83b72a

	$user->wallet->decimal_places = 18;
	$user->wallet->save();
	$math = app(MathServiceInterface::class);
	$user->depositFloat('545.8754855274419');

laravel-wallet/tests/Units/Domain/WalletFloatTest.php

Lines 292 to 313 in a83b72a

	$user->wallet->decimal_places = 32; // bitcoin wallet
	$user->wallet->save();
	$math = app(MathServiceInterface::class);
	// optimize
	app(DatabaseServiceInterface::class)->transaction(function () use ($user) {
	for ($i = 0; $i < 256; ++$i) {
	$user->depositFloat('0.00000001'); // Satoshi
	}
	});
	self::assertSame($user->balance, '256' . str_repeat('0', 32 - 8));
	self::assertSame(0, $math->compare($user->balanceFloat, '0.00000256'));
	$user->deposit(256 . str_repeat('0', 32));
	$user->depositFloat('0.' . str_repeat('0', 31) . '1');
	[$q, $r] = explode('.', $user->balanceFloat, 2);
	self::assertSame(strlen($r), $user->wallet->decimal_places);
	self::assertSame('25600000256000000000000000000000001', $user->balance);
	self::assertSame('256.00000256000000000000000000000001', $user->balanceFloat);

The issue is not the difficulty of leaving only one type, but the fact that the package will be 5 years old this year. We need to be conservative and support old projects. Also, do not forget that float methods in real time constantly recalculate the balance, which adds a large load. Conversion is not free.