Considering that contrary to Doctrine, Eloquent does not define data structure through model description but from migrations, I considered another option: I’m considering both deflecting the migrations by replacing the Schema Facade by another and do a post-analysis of the models retrieved through the migrations to get their relationships.

I have still no idea where to start from and maybe you’ll think this is madness, but I’d like to get your advices about it.

So far, here is the raw plan:

• create a CustomSchema class extending Facade and providing an object of type CustomBuilder extending Illuminate\Database\Schema\Builder and implementing the business logic for the creation of an array of models and fields
• create some kind of action class that will :
  • switch Schema with CustomSchema before calling the execution of the migrations;
  • browse all retrieved model classes’ methods returning an object of type Illuminate\Database\Eloquent\Relations\Relation, and note them as relationships
  • store the resulting array of data

The action would be callable either from a console command or after execution of a regular migration

What do you think of it? How could I achieve that?

When I posted this scenario on larachat, I was finally responded that it was too complicated and that it ignored the fact that a model name could be different of the table name. So I was suggested to take inspiration from barryvdh/laravel-ide-helper to analyze model files directly. To be continued, probably.

Also needed to know how to do this. for a moment i thought about parsing the migration file but your way sounds more flexible. keep on updating us

Not sure how far you got but there are a few commands to help you out but I think you will probably be best off doing it in raw querys.

If you open up tinker you can play around with these...

\Schema::getColumnListing('tableName');

This will return the column name's itself using the default connection found on your projects. However if you do something like

\Db::select(\DB::raw('SHOW COLUMNS FROM tableName'));

You will get something way better.. however, then you run into things like MySQL vs Postgres, etc. For example I used the describe method on a package I wrote to help make models a little bit easier, but describe doesn't exists in postgres (https://github.com/laracademy/generators/blob/master/src/Comma...) just something to keep in mind