On 4/25/06, Ed Singleton <[EMAIL PROTECTED]> wrote:
you can trust the dump functions, what you shouldn't trust that much is moving from db vendor a to b.
The main problem with that is that there is no way to know what and how was change, if you change the name if a column.
What can convince the software that a column was erase and a new one was created over a rename? Also if you change a relationship all your schema is mess up, This is not a problem with TG or python, it's a real problem of the relational table model, so far the only good way of doing this is with alter table statements and code versioning, which breaks SQLObject ;(
On 24/04/06, jvanasco <[EMAIL PROTECTED]> wrote:
>
> why not just use the dump feature in sqlite/mysql/pgsql
>
> all dbs have a 'dump' function/app that exports the contents to a
> generic format that can be read/altered to be read by another db
>
> going to pgsql you might have to run it through a filtering app, but
> mysql is pretty lax (just test your data to make sure its all there.
> probably best to run in 'traditional sql' mode if you have 5.0 )
Part of my reason for this is that Python seems to be a lot easier
than fiddling around with SQL and databases, but the dump thing seems
quite easy.
Testing my data to see if it's all there could be a nightmare though:
loads of tables with thousands of entries each.
you can trust the dump functions, what you shouldn't trust that much is moving from db vendor a to b.
> > I need to bear in mind here that when I put the data back in (with a
> > simple script) some of the class names or field names might have
> > changed, so I will need another nested dictionary (?) of changes that
> > will override the other dictionary.
>
> Thats a nightmare. backup your db on box 1, coerce your data into the
> new schema, and export to ascii with a dump utility. (when i do stuff
> like that, i keep a log of all the necessary sql commands) making
> filters to change data will just be a nightmare.
I was hoping not to do all this (I know quite little of SQL), but I
guess you're right though.
It does seem like there is a need to do stuff like this in TG though.
Altering your class definitions seems to be a lot more work than it
should be when you've got data in the table.
The main problem with that is that there is no way to know what and how was change, if you change the name if a column.
What can convince the software that a column was erase and a new one was created over a rename? Also if you change a relationship all your schema is mess up, This is not a problem with TG or python, it's a real problem of the relational table model, so far the only good way of doing this is with alter table statements and code versioning, which breaks SQLObject ;(
Thanks
Ed
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
- [TurboGears] Re: Dumping Data from Model Jorge Vargas
- [TurboGears] Re: Dumping Data from Model Ed Singleton
- [TurboGears] Re: Dumping Data from Model Jorge Godoy
