Clarify precision/scale

[dereuromark]

I think we need to clarify the differences between Cake and Phinx, regarding the option keys precision, scale and limit.

The correct phinx migrations lines are:

$table->changeColumn('lat', 'float', [
			'default' => null,
			'null' => true,
			'precision' => 10,
			'scale' => 6,
		]);
		$table->changeColumn('lng', 'float', [
			'default' => null,
			'null' => true,
			'precision' => 10,
			'scale' => 6,
		]);

In the fixtures it is, though:

'lat' => [
    'type' => 'float', 
    'length' => 10, 
    'precision' => 6,
    'unsigned' => false, 
    'null' => true, 
    'default' => null,
],
'lng' => [
    'type' => 'float', 
    'length' => 10, 
    'precision' => 6, 
    'unsigned' => false, 
    'null' => true, 
    'default' => null,
],

precision/scale vs length/precision can be rather confusing IMO.

[dereuromark]

Is there anyone with similar experience - and some more insight? We could make a small note in the docs here to avoid other people to trip over the same thing.

[markstory]

That is pretty confusing. We could start accepting scale in the fixtures. But changing the meaning of precision in either migrations or fixtures is going to be problematic.

[HavokInspiration]

This is regular problem with phinx : some options are not named the same. The signed / unsigned features on numeric columns was also a problem. We implemented it as some DB engines do (with an unsigned option ; phinx did it the other way around, with a signed option.

Same thing goes for the autoIncrement feature. Phinx implements it with a identity named option.

This is what I did in the past to offer a more common interface : https://github.com/cakephp/migrations/blob/master/src/Table.php#L51-L54

But I'm not sure this is good, it adds a bit of complexity when maintaining.

[HavokInspiration]

As for a note in the docs why not... It can't hurt much.