3.0 - Schema subsystem wiki page

[mark_story]

Hey everyone,

Now that there has been some progress on the basics of the database layer for 3.0, I was going to get started on the Schema subsystem. I feel there are a few problems with the current one. The logic is spread between CakeSchema and the various dbo classes, caching is implemented in the incorrect place as well. I feel that there should be a more complete schema system that can be used to build other tools like migrations on top of more simply than now.

I've tried to capture most of the changes I think should be made in the following wiki page: https://github.com/markstory/cakephp/wiki/Schema-subsystem

I'd love to hear any feedback people have before work gets started on the code.

-Mark

[Juan Basso]

I liked it. Seems each peace will not be complex and all together will be very useful.

I just missed the extra parameters for columns, like auto increment (or sequence in pgsql).

-Mark

--
You received this message because you are subscribed to the Google Groups "cakephp-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cakephp-core...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Saleh Souzanchi]

Is excellent.
My suggestion: Support from the View / Trigger / Function

[mark_story]

You mean support them as part of the eventual migrations tooling? Or be able to reflect them as well?

-Mark

[Saleh Souzanchi]

It means:
These features add to CakeSchema
CakeSchema able to create view / trigger

On Mon, Apr 15, 2013 at 6:18 AM, mark_story <mark....@gmail.com> wrote:

CakeSchema

     Best Regards
   Saleh  Sozanchi
 * * * * * * * * * * * * *

Mobile : +98 918 111 7209

Phone : +98 811 823 4448

http://soozanchi.ir
http://cakephp.ir

[mark_story]

Thanks, I'll add in some ways to create procedures/views. I don't think they'll be implementable in a portable cross vendor way. But I don't really see that as an issue personally.

-Mark

[Andy Hobbs]

This seems to be very good and a huge improvement on the current schema support. 

My only extra request would be to support fixed length strings via schema objects as this is the main thing stopping me using the schema stuff so far. Working with MySQL I generally use char not varchar for short strings where I might need indexing, such as Model name on polymorphic relationships

--

[mark_story]

Hey Andy,

Perhaps fixed length char's should be a different type, or an additional flag for the string type? Would something like 

'type' => 'string',

'fixed' => true,

'length' => 11

Does that seem like a reasonable way to spell what you're thinking of?

-Mark

[Andy Hobbs]

Hi,

'fixed' => true seems to be the the cleanest cross db solution as keeping the type as just string is most appropriate from the point of view of the underlying PHP type.

An alternative I considered a while ago was to include the underlying datatype or even column definition so that unsigned ints would work as well,  but this makes migrating between database types/versions a potential problem and also makes the comparison functionality very difficult to implement.

Unsigned itself could be handled by also adding in 'unsigned' => true as an option but then where do you stop...

So I guess to answer your question, for my use adding 'fixed' => true would suffice

Thanks

Andy

[Andy Hobbs]

I've been thinking about this a bit and there are a couple more scenarios (working with MySQL) that come up in a few of my projects that the current schema implementation doesn't handle:

Decimal - precision can map to length but there is no representation of scale

[tiny|medium|long]text - The MySQL database driver could work these out based on the length parameter which would make it fully cross DB compatible.

[mark_story]

I've gotten the first pull request for this set of changes up:

https://github.com/cakephp/cakephp/pull/1252

Any feedback/comments you have are appreciated :)

-Mark