Builds ORM directly from MySQL database definitions supports Node Sequelize and PHP Laravel Eloquent

I have always thought that your MySQl field names should be so obvious that you could programmatically create your ORM objects from them.

I love the ORM style of Laravel Eloquent and Nodes Sequelize.

This script will auto generate ORMS for those projects from any MySQL database you point it to. The constraints on table definitions are much stricter for Sequelize so it will complain when those do not match.

Hopefully this will make it easier to use Node and Laravel together by sharing data between them using MySQL.

Or it could be a terrible idea. It's so hard to tell sometimes.

I hope this saves you some time.

I will try and write the code such that you could create other ORM files with mere templates...

It would be nice to be able to auto-generate everything... but that is not life... so we have three levels of inheritance that help us customize what the autogenerated code does.

BaseORM.php < extends Eloquent with stuff that we want all of our objects to have (i.e. code to do an alpaca form automatically) ThingState_Base.php < Extends BaseORM.php and has all of the functions that we can autogenerated. ThingState.php < Extends ThingState_Base.php. This one is auto-generated, but will not be overwritten by further autogeneration... so you can save your customizations here without fear of getting clobbered by code-generator.

For instance when the auto-generated code cannot tell if a relatioship should be "hasOne" or "hasMany" then you can copy that function to the highest level class and put the right answer there..

• We take the 's' off of the table name to get the singlular
• You must have AutoIncrement and PRIMARY key set on the 'id' field of each table
• So never name your table ThingStatus because that becomes ThingStatu when we make it singular.
• Instead use ThingStates, which works right...
• If you want to link a field to the id of another table, then ensure that you end the field name with ThingState_id
• you can have more than one, so Another_ThingState_id and AFine_ThingState_id will both work as expected
• Many to many relationships, etc are hard to detect... but the auto-generated code will make
• mostly, the naming matters for the auto-form generation, as per:
• if you end code with _date it will use a HTML calendar datetime picker
• if you refer to another table, the form generator will try to pull the contents of that table into the form as a select element
• the label for the select element will be based on any field that ends in _name
• However, if there is a field called select_name then the system understands that to be the real right answer and will use that as the select name
• otherwise the last _name field in a table is used.
• if the fields beigns with is_ then it is regarded as being a boolean and will be replaced with a checkbox or a radio button...

if you add the following fields at the end of your table, then Laravel and Sequelize will both be very happy...

ALTER TABLE `ThingState`
ADD `created_by_User_id` INT(11) NOT NULL,  
ADD `modified_by_User_id` INT(11) NOT NULL,  
ADD `created_at` DATETIME NOT NULL,  
ADD `updated_at` DATETIME NOT NULL

Every table must have the following additional fields if it is to be editable via the ORM..

Note the strangeness of having "updated" and "modified" there may have been a reason that I did that.

Because we build function names from the field names in the table, we have to have some limitations. You can start a field with a digit '1', or '0' but you cannot start a function that way.. so beware...

Clone the repo. Create the output directories.. for now these are...

larvavel/eloquent/ node/sequelize/

Then copy the config.yaml.template to config.yaml with your MySQL database information. As long as you have correctly created the MySQL tables as listed above, the code should be able to auto-generate the corressponding Laravel and Sequilze ORM code. Which you do by running...

php buildORM.php

This will build two files per class, a "Base" class, which always has the autogenerated code, and a class that extends the base class for each table. When you run subsequent compiles the Base class will always be overidden but the extending class will not be, allowing you to write your own methods and goodness on top of the Base autogenerated classes, without worry that it will be overwritten by a compile.

I will improve this project and return to it over time, but I am not actively using it. So your milage may vary. Having said that, if you want to take over maintainership, I would be more than likely to refer to your fork!!