vpremiss / crafty Goto Github PK

I noticed that we're often doing many chains of validations for arrays and their values, and even more when it's a associative array and where keys are now crucial; let alone indenting (recursion) of that. Therefore, I think it would be extremely valuable to create a custom Laravel Validation Rule to help with this.

And then apply the rule everywhere in other packages and projects.

Ensure array validator does not deal with empty arrays, even inner ones

Integrate Arabicable's seeder management logic to CraftyPackage

I'm working currently on cleaning the mess in Arabicable's default installation command that's provided by Spatie's package tools package by moving it to a custom command.

Dealing with seeding is a mess - ensuring that it works in all environments, so I'm working a managing logic of sort. And I need you to integrate it please.

Keep your eyes peeled, over! @Haaabeeel

seeder files acquiring during installation fails for multiple

If multiple seeder files are defined and passed to the interface method, installation fails because of a wrong way of combining arrays or something!

Tests for database insertion helper method

Way better documentation for Configurated utility

This feature became very helpful and essential for Laravel package development; explain this!

We need better documentation for CraftyPackage methods that are related to handling configruations...

Enumerified methods are faulty, testing required!

Abstract the model "data" concept from SDQ project

I'll see if I can make the boilerplate easier.

What's SDQ? None of your b-. (Ehmm) It's a... it's in our sponsorship page! :)

add a "asCollection" return boolean arg to filterProps

Maybe FilledString as a new data type

A helper method for deriving the class manually in a package

// TODO abstract
$namespace = $serviceProvider->getPackageNamespace();
$className = str($path)->after('seeders/')->before('.php')->value();
$className = "{$namespace}\\Database\\Seeders\\$className";

And maybe adding the requiring logic too? on CraftyPackage facade perhaps

filterProps to deal with 'only' and 'except' common situation

Composer or Orchestra for all I care is considering the latest main branch only!

I talked about it in this PR #33 .

Add a config_with_default() or move the functions to the facade instead

Inside the configuration trait, we'd use config('x', $this->configDefault('x')), which can be abstracted with ease. But then realizing that it's a global function everywhere is kind of bad...

Maybe we should just move it to a new CraftyPackage facade or something. 👍

CI shouldn't run twice upon merging to main

Abstract the manual seeding approach to CraftyPackage

The same approach we had previously during package installation commands by pulling and then instantiating the classes and running their run() methods manually.

Extract the service provider's namespace from the package short name

For CraftyPackage::validatedConfig() method

What if new configurations aren't found in config file?

Mapping closure to filterProps, to apply on the final outcome before returning as array

Standardize configuration to work anywhere!

We have a problem!

Currently, relying on configurations internally cause not only issues with testing environments (where the app structure is like Orchestra's or something), but also we also face abstraction issue where we do validations right after every call for config() to ensure working with a sane value!

The solution I'm working on is to implement configuration defaults and validations on the package service provider (any other package's really, since we're a helper package, yet including ourselves too), and then globalizing a validated_config() helper function to do exactly that.

What do you think? @GoodM4ven

Skipping chunked insertions for existing records

use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\QueryException;

public function chunkedDatabaseInsertion(string $tableName, array $dataArrays, ?Closure $callback = null): void
{
    $callback ??= fn ($dataArray) => $dataArray;
    $chunksCount = CraftyPackage::getConfiguration('crafty.databasing_chunks_count');
    $defaultProperties = CraftyPackage::getConfiguration('crafty.insertion_default_properties');
    $columnNames = Schema::getColumnListing($tableName);

    DB::beginTransaction();
    try {
        $chunks = array_chunk($dataArrays, $chunksCount);

        foreach ($chunks as $chunk) {
            // Retrieve existing records to skip duplicates
            $existingRecords = DB::table($tableName)
                ->whereIn('email', array_column($chunk, 'email'))
                ->pluck('email')
                ->toArray();

            $data = array_map(function ($dataArray) use ($tableName, $callback, $columnNames, $defaultProperties, $existingRecords) {
                $callbackData = $callback($dataArray);

                if (!is_array($callbackData)) {
                    throw new CraftyDatabaseException(
                        'The callback must return an array for each data arrays item.'
                    );
                }

                // Skip duplicates
                if (in_array($callbackData['email'], $existingRecords)) {
                    return null;
                }

                $validatedData = array_filter($callbackData, function ($key) use ($columnNames) {
                    return in_array($key, $columnNames);
                }, ARRAY_FILTER_USE_KEY);

                if (empty($validatedData)) {
                    throw new CraftyDatabaseException(
                        "The callback array item does not return valid keys for the '$tableName' table."
                    );
                }

                return array_merge(
                    $validatedData,
                    $defaultProperties,
                );
            }, $chunk);

            // Filter out null values which are duplicates
            $data = array_filter($data);

            // Insert data if there are valid records
            if (!empty($data)) {
                DB::table($tableName)->insert($data);
            }
        }

        DB::commit();
    } catch (Exception $e) {
        DB::rollBack();

        throw $e;
    }
}

Add onInsertionException callback to the chunked insertion awesome method!

The only current weakness, as far as I know, in cases where an exception happen with not a very clear exception message...

A quick filled_string validator PLEASE!

Protected properties and methods cannot be used even on a container's service provider

Yep, my fear was in place:
VPremiss/Arabicable#18 (comment)

Specific enums validation

Abstract all the private laravel-package-tools stuff somehow, like getNamespace()

Currently, there is a lot of helper methods that are private when working with Spatie's Laravel package tools, such as getting the package name using $this->package->shortName(); where package itself is protected anyway... Having public methods that internally call these on the service provi- oh wait! We actually have those in HasInstallationCommand!

So all we need is a new trait that contains them and that is pulled by that other trait anyway. -oh and adding its methods to the installable interface for clarity..

vpremiss / crafty Goto Github PK

crafty's Issues

What happened?

How to reproduce the bug

Package Version

PHP Version

Laravel Version

Which operating systems does with happen on?

Notes

Recommend Projects

Recommend Topics

Recommend Org

Jobs