-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use different Eloquent models for different collections #21
Comments
Great feature request. Maybe a duplicate of #11 though? |
They are similar, but the feature discussed in #11 would still use the same Eloquent model/database table for the selected collections, whereas what I am proposing here is that it would also be possible to specify a Model per collection. |
Fair enough, will leave open. |
Is this not exactly what the Runway add-on lets you do? https://statamic.com/addons/double-three-digital/runway |
Hey folks. I'm also REALLY needing this. In my case, all I need is to have each collection in its own table. There's no need for each field to be in a separate column. So, my idea was this: When a new collection is created, we only need to create the Then, I thought to simply use the same At first I thought I could simply tweek the High heavens frustration levels. Does anyone have some sort of direction to this? |
For this use case I highly recommend using Runway |
I would really like to use Statamic in a project with a traditional datbase layout, but it looks like it's impossible or very difficult.
I have tried following the code in this repository (and the guide in the knowledge base) to implement this myself. It seemed promising since Statamic uses a repository, but currently this driver (and Statamic in general) assumes that all entries, in any collection, are stored in a single database table. This approach works when using a JSON
data
column, but fails when trying to apply it to a more traditional database layout where different kinds of content are stored in different tables.Also when trying to see if I could somehow get around this limitation by making a clever QueryBuilder implementation I noticed that many of the interfaces (like
Statamic\Contracts\Entries\QueryBuilder
) are empty, so it's difficult to know what methods need to be implemented.Anyway, is this feature even possible to implement?
The text was updated successfully, but these errors were encountered: