search

JaquelineBrandao / yii

Automatically exported from code.google.com/p/yii
0 stars 0 forks source link

Add model-database synchronize tool #155

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
In the development process, there's a good chance of changing the database.
When we changed the db or model, we need to make these changes to model or
db respectively, to maintain the consistency.
I think we need a tool to do this synchronization for us automatically, so
the db scheme can be maintained in one place only. Some other frameworks
like rails and django have a syncdb command to do this job.
As the table scheme is not presented in the AR model of Yii, this feature
might cause some changes to the model's structure.

Original issue reported on code.google.com by leric.zh...@gmail.com on 19 Feb 2009 at 2:00

GoogleCodeExporter commented 9 years ago

Original comment by qiang.xue on 19 Feb 2009 at 2:16

GoogleCodeExporter commented 9 years ago 
For one of my own projects, I wrote a parser for embedded model-specifications 
- e.g.
model classes looking like this:

http://code.google.com/p/shortr/source/browse/trunk/test/TestModel.class.php

As you can see, embedded model-specifications are simply SQL-hints embedded in 
the
source code of a model-class. This way, you can have a single-source model, 
with the
SQL specification embedded and visible to the developer in one place.

I like this approach, because it removes all duplication from the modeling
work-process - you don't need to write DDL/SQL schema separately, you don't 
need to
maintain a list of properties as comments (which gets outdated as your models 
evolve,
because you forget to update them), and you don't need to manually handle most
migrations (e.g. add/remove columns, which covers about 90% of migrations). You 
also
don't need to manually re-state maximum string lengths for validations, these 
could
easily be auto-configured from the model-specification.

My parser is here:

http://code.google.com/p/shortr/source/browse/trunk/shortr.org/class/ShModelSpec
Parser.class.php

Note that this is just the parser, I haven't written an actual 
schema-synchronizer.
Also note that this is part of my own (unfinished) mini-framework, porting it 
to Yii
should be very straight-forward though.

Also, other bits and pieces are missing, like storing the resulting
model-specifications in a runtime folder...

But it's a start :-)

Original comment by rasmus.m...@gmail.com on 1 Sep 2009 at 3:38

GoogleCodeExporter commented 9 years ago 
This is theoretically very sounding, but practically it may face a lot of 
problems.
Actually, I had a similar discussion with a developer of another popular 
framework.
If you only intend to support one DBMS, you may face less problems. Still, it 
means
educating users to adopt a totally new development strategy, which is not 
always easy.

Original comment by qiang.xue on 10 Sep 2009 at 7:58

GoogleCodeExporter commented 9 years ago 
What kind of problems? If we plan it well, we might be able to design around 
those.

But this feature could probably be developed as an add-on anyhow.

As far as keeping data structures portable between different DBMS, in my 
experience, 
even when you struggle to make portable data structures, this never truly 
happens - 
and in the lifetime of 99% of any project, you will never need to switch the 
DBMS 
anyhow.

Using SQL hints, I don't see the big problem in terms of supporting different 
DBMS 
though - you would need a driver for each engine of course, supplying things 
like 
valid keywords, etc.

That won't make the data structures portable, but it could make this feature 
compatible with different DBMS.

One approach I don't like, is that of Rails' Active Migrations - abstracting 
the data 
structure creation from SQL entirely is just not an approach I'm comfortable 
with. 
There are too many differences between DBMSes, and trying to abstract from 
these puts 
you too far from the engine. For example, I know MySQL extremely well, I'm 
extremely 
comfortable with it, and I don't want to remove myself from the unique features 
and optimizations I can do with it.

Note that this is not really a solution designed to abstract from SQL/DLL - 
it's a 
means of reducing redundancy, and placing the data structure specification 
where it's 
visible to the developer, as well as speeding up SQL/DDL development and 
deployment.

Original comment by rasmus.m...@gmail.com on 11 Sep 2009 at 2:27

GoogleCodeExporter commented 9 years ago 
Do you know this project? http://www.ezpdo.net/blog/?p=2

I have no doubt that this approach may work very well for small applications. 

However, for bigger applications, database design is much more complicated than 
can
be cleanly represented in terms of classes.

Original comment by qiang.xue on 11 Sep 2009 at 2:40

GoogleCodeExporter commented 9 years ago 
I did not know ezpdo - but from the description, it sounds nothing like what I 
have 
in mind.

It appears to be all about abstracting from SQL ("minimum SQL knowledge 
required"), 
automating table generation, automatic relationship management, etc. - these 
are none 
of the things I'm looking for.

I want to design a system where the schema specification can be embedded in the 
code, 
using SQL hints, where applicable, or raw SQL for special cases - not a system 
that 
generates schema. Not a replacement for SQL, just a different way to store 
relevant 
table schema with the class it belongs to.

I have worked on very big applications, so I know that databases get way more 
complicated than you can handle with a system of this type.

I am not simply looking for abstraction, shortcuts or "magic" - I am looking 
for a 
better way to organize schema and code, and keep them together. Schema is 
traditionally more or less completely detached from code, and it just doesn't 
seem 
right - we spend too much time simply coming up with ways to cope with this 
detachment.

Anyway, I'm hoping to produce a working prototype at some point, so you can see 
what 
I'm talking about. If/when I get there, I will be posting in the forum :-)

Original comment by rasmus.m...@gmail.com on 11 Sep 2009 at 9:18

GoogleCodeExporter commented 9 years ago 
Sure. I am looking forward to seeing your prototype. In some sense, this 
affects the
whole development cycles. So maybe you could also describe the proposed way of
development when you present the prototype. Thanks!

Original comment by qiang.xue on 12 Sep 2009 at 12:19

GoogleCodeExporter commented 9 years ago

Original comment by qiang.xue on 17 Sep 2009 at 5:34

GoogleCodeExporter commented 9 years ago

Original comment by qiang.xue on 9 Jan 2010 at 9:05

GoogleCodeExporter commented 9 years ago 
maybe the rules() method of AR could also be a place to describe the schema like
array('id,post_count','define','int')
array('id','define','primary_key')
array('post_count','define','nullable','index')
furthermore, when forced to rename some field during devel we could add
array('post_count','define','rename:post_counter','revision:3')

Yii could then rename back and forth the database table fields(most 
conveniently preserving data) just by looking at a param named 'revision' in 
the database component config from main.php

I'm using PHPDataMapper http://phpdatamapper.com/
(which is a beta) and an ActiveRecord subclass to achieve this, but it would be 
simply wonderful to have it in the core

Please take note that guessing renames by comparing sql table schema with model 
schema is virtually impossible. so the "rename" feature would be nice

From my point of view the rules() should also hint about the database 
structure, since AR has to rely on SQL to store the data. So why not keeping 
all these together, business validation and actual table structure?

Original comment by tudorili...@gmail.com on 23 Mar 2011 at 4:40

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Looking at this today, two years later, I realize that what I was doing back 
then was actually a simple form of source code annotation.

Thinking about this today, I don't believe it would make any sense to write a 
separate parser and a special framework for this feature - it should be 
implemented using source code annotations, which, down the line, could also 
potentially eliminate many other points of duplication in models, forms, etc... 
this would also eliminate any storage-engine-specific SQL syntax in the model 
annotations...

Original comment by rasmus.m...@gmail.com on 17 Apr 2011 at 4:30

GoogleCodeExporter commented 9 years ago 
Please, something like django's models!
http://docs.djangoproject.com/en/dev/topics/db/models/

Original comment by jorge.ba...@gmail.com on 7 May 2011 at 10:30

GoogleCodeExporter commented 9 years ago 
(Sorry for double comment)

The rules (http://www.yiiframework.com/doc/api/1.1/CModel#rules-detail) should 
be generated automatically if you define the model with fields, like django.

Original comment by jorge.ba...@gmail.com on 7 May 2011 at 10:50

GoogleCodeExporter commented 9 years ago 
Migrated to http://github.com/yiisoft/yii/issues/299

Original comment by qiang.xue on 15 Feb 2012 at 6:48