I'm used to Propel2, which allows me to build a scheme in a designer (like Skipper18) and then with some CLI magic allows me to update the database according to the new/updated scheme.
It then allows me to automagically build the models according to that scheme.
I've noticed that with FuelPHP, I have to build models manually and can't use a scheme file like with Propel.
I know that it would take a boatload of time and effort, but I think that allowing this options could save developers a lot of time in the long run.
Skipper18 is buyware, so I think for the price they could include it? They include plenty of others?
Personally I've never feld the need, I create the base models quicker than I can draw them in a tool.
And if you can draw them in a tool, you can usually generate the database from it, and then use the oil fromdb task to generate models and migrations from your database tables.
Skipper18 can't do that by it's own as far as I know (it just creates the scheme then exports it for stuff like Propel, Doctorine, MongoDB and CakePHP, who then can be used to actually create the database)
I think that if it doesn't come as a standard functionality in FuelPHP, then I should go and see if I can build something myself instead.
I used Skipper18 as an example here because it's the software that I'm used to.
There should be some more options (I think MySQL workbench can do it as well, but I need a citation on that).
I think to be able to build models and migrations from an XML scheme could be a nice speedup.
I've seen a lot of people using ORM designers, so that's why I brought up the topic.
From what I can see it Skipper18 supports creating your own template. My point was only that I don't see why we (or anyone else) should do that since it is commercial software.
For the rest I can only speak for myself: I never use tools like that, I start with writing migrations to create or alter tables, and then write or alter the models for those tables. Obviously not from scratch, I use a template.
The only manual work for the migrations are field definitions, and that is not extra work as you have to do that in your tool too. For the model, the only thing that can be generated is the field list and the relations, which are only a few lines.
Skipper18 is only so that people can make the designs in a graphical fashion (I think MySQL workbench can do the same for plain MySQL without ORM?).
I've seen one of my colleagues even using the plain XML to edit the schemes (yepp, he didn't even touch Skipper18 for it).
Again, Skipper18 was only an example since I use it, there are probably some other free alternatives to it, and/or maybe people build the XML files by hand.
At the moment, using the FuelPHP ORM means manually building the models, which adds an extra layer of "human work".
Yesterday I was working with a friend of mine on his site (which uses FuelPHP as well on my recommendation), and he builds the models himself... completely vulnerable to SQL injections.
This is why defining the structures in an XML and automagically build the models and migrations around it is a big win.
Less chance for human error.
But I'll guess I'll look into it myself to see if I can build functionality for this.
Once I've done so, I'll create a pull request (if I don't forget).
Though, I do still hope you'll take it in consideration as it would make FuelPHP's ORM a lot more interesting for others as well.
No matter what route you choose, there is always manual work involved.
My point is that I am quicker in creating a migration and a model than having to enter all the data into some graphical tool, do a lot of mouse fiddling, and then generate something. And repeat that on every change I need to make. ;-)
We will not spend any time on this, not because of this, but because we're not in the business of providing free support to commercial applications. I think you should direct this discussion towards Skipper18, and ask them to provide support for Fuel, like to do for other ORM's.
And your remark about a model being vulnerable for SQL injections is utter rubbish. SQL injections happen due to incorrect input validation, the model isn't involved in that. It might be that the model was used to generate a form and form validation, but in that cause the problem was not with the model, but with the input validation rules. Which are outside the scope of any database designer.
Besides that, simply having a GUI doesn't prevent any human error from happening.
But hey, if that is the way you work, and it works, who am I to say you should do it differently. ;-)
The point is, Skipper can't support FuelPHP like that.
Skipper exports schemes as `schema.xml` which Propel then use to build the models.
This means that it would be up to FuelPHP to support this.
Skipper (and some other software) can build the schema end export it, but then FuelPHP will have to build the models from it.
Here is an example of the scheme file that Skipper18 builds for another project I work on (which uses Propel).
As you can see, this is just an XML file with "instructions" on how Propel has to build the tables and models.
One then has to run the commands `propel model:build` (which reads the XML file and builds the ORM models based on it) and `propel diff` (to create the migration) followed by `propel migrate` (to actually run the migration).
That is what FuelPHP also should be able to do (the stuff that happens on the Propel side).
So in short:
- Skipper18: Create the schema in a graphical environment then export it as XML
- Propel: Create the Models based on the XML and create and run the migrations.
I hope you understand what I mean now.
It's not Skipper18 specific support, it's support to build models and migrations based on a schema file that one can make using Skipper18 (or other software).
Again, nobody is stopping you from creating an oil task to generate the required framework files from that xml, I'm just saying we're not going to do it, especially not since this is a commercial product so it requires people (including ourselfs) to buy it to benefit from it.
Donate
