I've been working on a new application and we decided to start with PHP version 8.1 since we're months away from any sort of app-launch and PHP 8.1 is due for GA release on 25th Nov 2021 (3 days).

I tried using the Laravel JSON API package and the only thing that seems like an issue for compatibility with PHP 8.1 is the use of the name ReadOnly. readonly is a reserved keyword in PHP 8.1 and causes a problem with the Interface and Trait in this package.

Thanks for all your work on these packages!

I've submitted a PR that appears to fix the issue. Hopefully it's of help:

#20

delimiter should default to , in filters such as WhereIn

I have built up a query within the Scheme::indexQuery() and I get the following exception when fetching the entities:

PDOException(code: 23000): SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'id' in order clause is ambiguous

This bug occurs when joining with other tables in the indexQuery(). The defaultOrder method within the PagePagination will only use the primaryKey in the orderBy causing this exception.

Feature related to This discussion

I'm helping to build a openapi spec generator but it seems it is not possible to get the column property of a filter. This makes collecting examples for the specification very hard.

Any chance we can make this method public?

     /**
     * @return string
     */
    protected function column(): string
    {
        return $this->column;
    }

This would enable us to generate column examples for filters without doing very weird (and ugly) things.

Currently isReadOnly and other ReadOnly methods requires $request to be provided but believe this should work statically.
Ex.
Str::make('name')->readOnly() marks the field readOnly
then when we do $field->isReadOnly() returns true
I believe we should also provide more methods such as isReadOnlyOnCreate and isReadOnlyOnUpdate which will work without providing request

so we will have following

    private $readOnlyOnCreate = false;
    private $readOnlyOnUpdate = false;

   public function readOnlyOnCreate(): self
    {
        $this->readOnlyOnCreate = true;
        return $this;
    }

   public function isReadOnlyOnCreate(): self
    {
        return $this->readOnlyOnCreate;
    }

    public function isReadOnly($request = null): bool
    {
        if(empty($request)) return $this->readOnlyOnCreate || $this->readOnlyOnUpdate;
        return ($request->isMethod('PATCH') && $this->readOnlyOnUpdate) || ($request->isMethod('POST') && $this->readOnlyOnCreate);
    }    

Or please check this from Nova

I personally prefer the first option as it is not dependent on the request parameter

This will allow us to use figure out if the field is readOnly while writing packages. or extending functionality.

I really don't know a lot about the code base but while checking i saw that All fields don't have same methods. This makes life hard while developing packages or extending the fields.

it will be great if they have common methods such as column, name, fill, serializeUsing, etc.

Use Case

I have a model, Calendar, which has events from the database (An Eloquent model occasion)
But now, I am adding support for external events, such as an ICalendar Feed (a URL for .ics files)

I can get the data into Laravel pretty easy, and I have a relationship on calendar called occurrences which combines occasions and all external events into a collection. Data has attributes to distinguish the source and ids, so my custom repository can handle CRUD operations.

I need to be able to interact with this via JSON API at the route /calendars/{calendar}/occurrences

Code changes

The issue, is that that the following code checks specifically if the Schema is an Eloquent Schema.

I could resolve this, by making the typecheck compare against LaravelJsonApi\Core\Schema\Schema instead of LaravelJsonApi\Eloquent\Schema

But this opens a whole new can of worms. Thinks like Paginator, and another type check at:

Conclusion

I am very much willing to assist in any code development needed here, but it seems to me like a lot of code is going to need to be touched to trick this library to be able to support non-eloquent relations.

I figure, the best bet, is to try and move some of this logic up to the Core Level, so that any LaravelJsonAPI schema.
And my current efforts are to reduce the scope of the Type Checks to the Core Level. That being said, I'll also need to move some of the logic from the eloquent library to the core library, to fix some of these type checks.

Let me know if y'all have any concerns, or if there are any ongoing efforts that I can assist.