bhavin-gajjar/laravel-coder-lora-train huggingface dataset:
[Laravel 10] Explain pennant: Configuration

After publishing Pennant's assets, its configuration file will be located at config/pennant.php. This configuration file allows you to specify the default storage mechanism that will be used by Pennant to store resolved feature flag values.

Pennant includes support for storing resolved feature flag values in an in-memory array via the array driver. Or, Pennant can store resolved feature flag values persistently in a relational database via the database driver, which is the default storage mechanism used by Pennant.

<a name="defining-features"></a>
[Laravel 10] Explain pennant: Defining Features

To define a feature, you may use the define method offered by the Feature facade. You will need to provide a name for the feature, as well as a closure that will be invoked to resolve the feature's initial value.

Typically, features are defined in a service provider using the Feature facade. The closure will receive the "scope" for the feature check. Most commonly, the scope is the currently authenticated user. In this example, we will define a feature for incrementally rolling out a new API to our application's users:

As you can see, we have the following rules for our feature:

- All internal team members should be using the new API.
- Any high traffic customers should not be using the new API.
- Otherwise, the feature should be randomly assigned to users with a 1 in 100 chance of being active.

The first time the new-api feature is checked for a given user, the result of the closure will be stored by the storage driver. The next time the feature is checked against the same user, the value will be retrieved from storage and the closure will not be invoked.

For convenience, if a feature definition only returns a lottery, you may omit the closure completely:

    Feature::define('site-redesign', Lottery::odds(1, 1000));

<a name="class-based-features"></a>
[Laravel 10] Explain pint: Introduction

Laravel Pint is an opinionated PHP code style fixer for minimalists. Pint is built on top of PHP-CS-Fixer and makes it simple to ensure that your code style stays clean and consistent.

Pint is automatically installed with all new Laravel applications so you may start using it immediately. By default, Pint does not require any configuration and will fix code style issues in your code by following the opinionated coding style of Laravel.

<a name="installation"></a>
[Laravel 10] Explain pint: Running Pint

You can instruct Pint to fix code style issues by invoking the pint binary that is available in your project's vendor/bin directory:

You may also run Pint on specific files or directories:

Pint will display a thorough list of all of the files that it updates. You can view even more detail about Pint's changes by providing the -v option when invoking Pint:

If you would like Pint to simply inspect your code for style errors without actually changing the files, you may use the --test option:

If you would like Pint to only modify the files that have uncommitted changes according to Git, you may use the --dirty option:

<a name="configuring-pint"></a>
[Laravel 10] Explain pint: Configuring Pint

As previously mentioned, Pint does not require any configuration. However, if you wish to customize the presets, rules, or inspected folders, you may do so by creating a pint.json file in your project's root directory:

In addition, if you wish to use a pint.json from a specific directory, you may provide the --config option when invoking Pint:

<a name="presets"></a>
[Laravel 10] Explain precognition: Precognition

- Introduction
- Live Validation
    - Using Vue
    - Using Vue and Inertia
    - Using React
    - Using React and Inertia
    - Using Alpine and Blade
    - Configuring Axios
- Customizing Validation Rules
- Handling File Uploads
- Managing Side-Effects
- Testing

<a name="introduction"></a>
[Laravel 10] Explain precognition: Introduction

Laravel Precognition allows you to anticipate the outcome of a future HTTP request. One of the primary use cases of Precognition is the ability to provide "live" validation for your frontend JavaScript application without having to duplicate your application's backend validation rules. Precognition pairs especially well with Laravel's Inertia-based starter kits.

When Laravel receives a "precognitive request", it will execute all of the route's middleware and resolve the route's controller dependencies, including validating form requests - but it will not actually execute the route's controller method.

<a name="live-validation"></a>
[Laravel 10] Explain precognition: Using Vue

Using Laravel Precognition, you can offer live validation experiences to your users without having to duplicate your validation rules in your frontend Vue application. To illustrate how it works, let's build a form for creating new users within our application.

First, to enable Precognition for a route, the HandlePrecognitiveRequests middleware should be added to the route definition. You should also create a form request to house the route's validation rules:

Next, you should install the Laravel Precognition frontend helpers for Vue via NPM:

With the Laravel Precognition package installed, you can now create a form object using Precognition's useForm function, providing the HTTP method (post), the target URL (/users), and the initial form data.

Then, to enable live validation, invoke the form's validate method on each input's change event, providing the input's name:

Now, as the form is filled by the user, Precognition will provide live validation output powered by the validation rules in the route's form request. When the form's inputs are changed, a debounced "precognitive" validation request will be sent to your Laravel application. You may configure the debounce timeout by calling the form's setValidationTimeout function:

When a validation request is in-flight, the form's validating property will be true:

Any validation errors returned during a validation request or a form submission will automatically populate the form's errors object:

You can determine if the form has any errors using the form's hasErrors property:

You may also determine if an input has passed or failed validation by passing the input's name to the form's valid and invalid functions, respectively:

> [!WARNING]  
> A form input will only appear as valid or invalid once it has changed and a validation response has been received.

If you are validating a subset of a form's inputs with Precognition, it can be useful to manually clear errors. You may use the form's forgetError function t
[Laravel 10] Explain precognition: Using Vue and Inertia

> [!NOTE]  
> If you would like a head start when developing your Laravel application with Vue and Inertia, consider using one of our starter kits. Laravel's starter kits provide backend and frontend authentication scaffolding for your new Laravel application.

Before using Precognition with Vue and Inertia, be sure to review our general documentation on using Precognition with Vue. When using Vue with Inertia, you will need to install the Inertia compatible Precognition library via NPM:

Once installed, Precognition's useForm function will return an Inertia form helper augmented with the validation features discussed above.

The form helper's submit method has been streamlined, removing the need to specify the HTTP method or URL. Instead, you may pass Inertia's visit options as the first and only argument. In addition, the submit method does not return a Promise as seen in the Vue example above. Instead, you may provide any of Inertia's supported event callbacks in the visit options given to the submit method:

<a name="using-react"></a>
[Laravel 10] Explain precognition: Using React

Using Laravel Precognition, you can offer live validation experiences to your users without having to duplicate your validation rules in your frontend React application. To illustrate how it works, let's build a form for creating new users within our application.

First, to enable Precognition for a route, the HandlePrecognitiveRequests middleware should be added to the route definition. You should also create a form request to house the route's validation rules:

Next, you should install the Laravel Precognition frontend helpers for React via NPM:

With the Laravel Precognition package installed, you can now create a form object using Precognition's useForm function, providing the HTTP method (post), the target URL (/users), and the initial form data.

To enable live validation, you should listen to each input's change and blur event. In the change event handler, you should set the form's data with the setData function, passing the input's name and new value. Then, in the blur event handler invoke the form's validate method, providing the input's name:

Now, as the form is filled by the user, Precognition will provide live validation output powered by the validation rules in the route's form request. When the form's inputs are changed, a debounced "precognitive" validation request will be sent to your Laravel application. You may configure the debounce timeout by calling the form's setValidationTimeout function:

When a validation request is in-flight, the form's validating property will be true:

Any validation errors returned during a validation request or a form submission will automatically populate the form's errors object:

You can determine if the form has any errors using the form's hasErrors property:

You may also determine if an input has passed or failed validation by passing the input's name to the form's valid and invalid functions, respectively:

> [!WARNING]  
> A form input will only appear as valid or invalid once it has changed and a validation r
[Laravel 10] Explain processes: Processes

- Introduction
- Invoking Processes
    - Process Options
    - Process Output
    - Pipelines
- Asynchronous Processes
    - Process IDs and Signals
    - Asynchronous Process Output
- Concurrent Processes
    - Naming Pool Processes
    - Pool Process IDs and Signals
- Testing
    - Faking Processes
    - Faking Specific Processes
    - Faking Process Sequences
    - Faking Asynchronous Process Lifecycles
    - Available Assertions
    - Preventing Stray Processes

<a name="introduction"></a>
[Laravel 10] Explain processes: Invoking Processes

To invoke a process, you may use the run and start methods offered by the Process facade. The run method will invoke a process and wait for the process to finish executing, while the start method is used for asynchronous process execution. We'll examine both approaches within this documentation. First, let's examine how to invoke a basic, synchronous process and inspect its result:

Of course, the Illuminate\Contracts\Process\ProcessResult instance returned by the run method offers a variety of helpful methods that may be used to inspect the process result:

<a name="throwing-exceptions"></a>
[Laravel 10] Explain prompts: Prompts

- Introduction
- Installation
- Available Prompts
    - Text
    - Password
    - Confirm
    - Select
    - Multi-select
    - Suggest
    - Search
    - Multi-search
    - Pause
- Informational Messages
- Tables
- Spin
- Progress Bar
- Terminal Considerations
- Unsupported Environments and Fallbacks

<a name="introduction"></a>
[Laravel 10] Explain prompts: Introduction

Laravel Prompts is a PHP package for adding beautiful and user-friendly forms to your command-line applications, with browser-like features including placeholder text and validation.

<img src="https://laravel.com/img/docs/prompts-example.png">

Laravel Prompts is perfect for accepting user input in your Artisan console commands, but it may also be used in any command-line PHP project.

> [!NOTE]  
> Laravel Prompts supports macOS, Linux, and Windows with WSL. For more information, please see our documentation on unsupported environments & fallbacks.

<a name="installation"></a>
[Laravel 10] Explain providers: Introduction

Service providers are the central place of all Laravel application bootstrapping. Your own application, as well as all of Laravel's core services, are bootstrapped via service providers.

But, what do we mean by "bootstrapped"? In general, we mean **registering** things, including registering service container bindings, event listeners, middleware, and even routes. Service providers are the central place to configure your application.

If you open the config/app.php file included with Laravel, you will see a providers array. These are all of the service provider classes that will be loaded for your application. By default, a set of Laravel core service providers are listed in this array. These providers bootstrap the core Laravel components, such as the mailer, queue, cache, and others. Many of these providers are "deferred" providers, meaning they will not be loaded on every request, but only when the services they provide are actually needed.

In this overview, you will learn how to write your own service providers and register them with your Laravel application.

> [!NOTE]  
> If you would like to learn more about how Laravel handles requests and works internally, check out our documentation on the Laravel request lifecycle.

<a name="writing-service-providers"></a>
[Laravel 10] Explain providers: Writing Service Providers

All service providers extend the Illuminate\Support\ServiceProvider class. Most service providers contain a register and a boot method. Within the register method, you should **only bind things into the service container**. You should never attempt to register any event listeners, routes, or any other piece of functionality within the register method.

The Artisan CLI can generate a new provider via the make:provider command:

<a name="the-register-method"></a>
[Laravel 10] Explain providers: The Register Method

As mentioned previously, within the register method, you should only bind things into the service container. You should never attempt to register any event listeners, routes, or any other piece of functionality within the register method. Otherwise, you may accidentally use a service that is provided by a service provider which has not loaded yet.

Let's take a look at a basic service provider. Within any of your service provider methods, you always have access to the $app property which provides access to the service container:

    <?php

    namespace App\Providers;

    use App\Services\Riak\Connection;
    use Illuminate\Contracts\Foundation\Application;
    use Illuminate\Support\ServiceProvider;

    class RiakServiceProvider extends ServiceProvider
    {
        /**
         * Register any application services.
         */
        public function register(): void
        {
            $this->app->singleton(Connection::class, function (Application $app) {
                return new Connection(config('riak'));
            });
        }
    }

This service provider only defines a register method, and uses that method to define an implementation of App\Services\Riak\Connection in the service container. If you're not yet familiar with Laravel's service container, check out its documentation.

<a name="the-bindings-and-singletons-properties"></a>
[Laravel 10] Explain providers: The `bindings` and `singletons` Properties

If your service provider registers many simple bindings, you may wish to use the bindings and singletons properties instead of manually registering each container binding. When the service provider is loaded by the framework, it will automatically check for these properties and register their bindings:

    <?php

    namespace App\Providers;

    use App\Contracts\DowntimeNotifier;
    use App\Contracts\ServerProvider;
    use App\Services\DigitalOceanServerProvider;
    use App\Services\PingdomDowntimeNotifier;
    use App\Services\ServerToolsProvider;
    use Illuminate\Support\ServiceProvider;

    class AppServiceProvider extends ServiceProvider
    {
        /**
         * All of the container bindings that should be registered.
         *
         * @var array
         */
        public $bindings = [
            ServerProvider::class => DigitalOceanServerProvider::class,
        ];

        /**
         * All of the container singletons that should be registered.
         *
         * @var array
         */
        public $singletons = [
            DowntimeNotifier::class => PingdomDowntimeNotifier::class,
            ServerProvider::class => ServerToolsProvider::class,
        ];
    }

<a name="the-boot-method"></a>
[Laravel 10] Explain pulse: Laravel Pulse

- Introduction
- Installation
    - Configuration
- Dashboard
    - Authorization
    - Customization
    - Resolving Users
    - Cards
- Capturing Entries
    - Recorders
    - Filtering
- Performance
    - Using a Different Database
    - Redis Ingest
    - Sampling
    - Trimming
    - Handling Pulse Exceptions
- Custom Cards
    - Card Components
    - Styling
    - Data Capture and Aggregation

<a name="introduction"></a>
[Laravel 10] Explain pulse: Installation

> [!WARNING]  
> Pulse's first-party storage implementation currently requires a MySQL or PostgreSQL database. If you are using a different database engine, you will need a separate MySQL or PostgreSQL database for your Pulse data.

Since Pulse is currently in beta, you may need to adjust your application's composer.json file to allow beta package releases to be installed:

Then, you may use the Composer package manager to install Pulse into your Laravel project:

Next, you should publish the Pulse configuration and migration files using the vendor:publish Artisan command:

Finally, you should run the migrate command in order to create the tables needed to store Pulse's data:

Once Pulse's database migrations have been run, you may access the Pulse dashboard via the /pulse route.

> [!NOTE]  
> If you do not want to store Pulse data in your application's primary database, you may specify a dedicated database connection.

<a name="configuration"></a>
[Laravel 10] Explain queries: Database: Query Builder

- Introduction
- Running Database Queries
    - Chunking Results
    - Streaming Results Lazily
    - Aggregates
- Select Statements
- Raw Expressions
- Joins
- Unions
- Basic Where Clauses
    - Where Clauses
    - Or Where Clauses
    - Where Not Clauses
    - Where Any / All Clauses
    - JSON Where Clauses
    - Additional Where Clauses
    - Logical Grouping
- Advanced Where Clauses
    - Where Exists Clauses
    - Subquery Where Clauses
    - Full Text Where Clauses
- Ordering, Grouping, Limit and Offset
    - Ordering
    - Grouping
    - Limit and Offset
- Conditional Clauses
- Insert Statements
    - Upserts
- Update Statements
    - Updating JSON Columns
    - Increment and Decrement
- Delete Statements
- Pessimistic Locking
- Debugging

<a name="introduction"></a>
[Laravel 10] Explain queries: Introduction

Laravel's database query builder provides a convenient, fluent interface to creating and running database queries. It can be used to perform most database operations in your application and works perfectly with all of Laravel's supported database systems.

The Laravel query builder uses PDO parameter binding to protect your application against SQL injection attacks. There is no need to clean or sanitize strings passed to the query builder as query bindings.

> [!WARNING]  
> PDO does not support binding column names. Therefore, you should never allow user input to dictate the column names referenced by your queries, including "order by" columns.

<a name="running-database-queries"></a>
[Laravel 10] Explain queries: Retrieving All Rows From a Table

You may use the table method provided by the DB facade to begin a query. The table method returns a fluent query builder instance for the given table, allowing you to chain more constraints onto the query and then finally retrieve the results of the query using the get method:

    <?php

    namespace App\Http\Controllers;

    use Illuminate\Support\Facades\DB;
    use Illuminate\View\View;

    class UserController extends Controller
    {
        /**
         * Show a list of all of the application's users.
         */
        public function index(): View
        {
            $users = DB::table('users')->get();

            return view('user.index', ['users' => $users]);
        }
    }

The get method returns an Illuminate\Support\Collection instance containing the results of the query where each result is an instance of the PHP stdClass object. You may access each column's value by accessing the column as a property of the object:

    use Illuminate\Support\Facades\DB;

    $users = DB::table('users')->get();

    foreach ($users as $user) {
        echo $user->name;
    }

> [!NOTE]  
> Laravel collections provide a variety of extremely powerful methods for mapping and reducing data. For more information on Laravel collections, check out the collection documentation.

<a name="retrieving-a-single-row-column-from-a-table"></a>
[Laravel 10] Explain queries: Retrieving a Single Row / Column From a Table

If you just need to retrieve a single row from a database table, you may use the DB facade's first method. This method will return a single stdClass object:

    $user = DB::table('users')->where('name', 'John')->first();

    return $user->email;

If you don't need an entire row, you may extract a single value from a record using the value method. This method will return the value of the column directly:

    $email = DB::table('users')->where('name', 'John')->value('email');

To retrieve a single row by its id column value, use the find method:

    $user = DB::table('users')->find(3);

<a name="retrieving-a-list-of-column-values"></a>
[Laravel 10] Explain queries: Retrieving a List of Column Values

If you would like to retrieve an Illuminate\Support\Collection instance containing the values of a single column, you may use the pluck method. In this example, we'll retrieve a collection of user titles:

    use Illuminate\Support\Facades\DB;

    $titles = DB::table('users')->pluck('title');

    foreach ($titles as $title) {
        echo $title;
    }

 You may specify the column that the resulting collection should use as its keys by providing a second argument to the pluck method:

    $titles = DB::table('users')->pluck('title', 'name');

    foreach ($titles as $name => $title) {
        echo $title;
    }

<a name="chunking-results"></a>
[Laravel 10] Explain queues: Queues

- Introduction
    - Connections vs. Queues
    - Driver Notes and Prerequisites
- Creating Jobs
    - Generating Job Classes
    - Class Structure
    - Unique Jobs
    - Encrypted Jobs
- Job Middleware
    - Rate Limiting
    - Preventing Job Overlaps
    - Throttling Exceptions
- Dispatching Jobs
    - Delayed Dispatching
    - Synchronous Dispatching
    - Jobs & Database Transactions
    - Job Chaining
    - Customizing The Queue and Connection
    - Specifying Max Job Attempts / Timeout Values
    - Error Handling
- Job Batching
    - Defining Batchable Jobs
    - Dispatching Batches
    - Chains and Batches
    - Adding Jobs to Batches
    - Inspecting Batches
    - Cancelling Batches
    - Batch Failures
    - Pruning Batches
    - Storing Batches in DynamoDB
- Queueing Closures
- Running the Queue Worker
    - The queue:work Command
    - Queue Priorities
    - Queue Workers and Deployment
    - Job Expirations and Timeouts
- Supervisor Configuration
- Dealing With Failed Jobs
    - Cleaning Up After Failed Jobs
    - Retrying Failed Jobs
    - Ignoring Missing Models
    - Pruning Failed Jobs
    - Storing Failed Jobs in DynamoDB
    - Disabling Failed Job Storage
    - Failed Job Events
- Clearing Jobs From Queues
- Monitoring Your Queues
- Testing
    - Faking a Subset of Jobs
    - Testing Job Chains
    - Testing Job Batches
- Job Events

<a name="introduction"></a>