Re: Schema Evolution Choices?
On Tue, Sep 2, 2008 at 12:37 AM, Jon Loyens <[EMAIL PROTECTED]> wrote: > > Hi guys, > > I have a small project coming up that I think having some sort of > schema evolution facilities will be handy on. I was wondering what > the current and best project choices for schema evolution are? I was > leaning towards django-evolution until I saw a post from Russell > saying that he hadn't updated it to the 1.0 branch yet. The key word here is _yet_. I'm expecting to do this update in the very near future, by which I mean "probably within a week". In the meantime, there are a number of patches in the django-evolution ticket repository that will fix many of the problems that have been caused by the recent changes to Django. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Schema Evolution Choices?
Hi guys, I have a small project coming up that I think having some sort of schema evolution facilities will be handy on. I was wondering what the current and best project choices for schema evolution are? I was leaning towards django-evolution until I saw a post from Russell saying that he hadn't updated it to the 1.0 branch yet. Any options or opinions are appreciated. Thanks, Jon. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
Thanks for all the valuable feedback guys, I went ahead and got Django Evolution up and running and I'll see what I think. This has been one thing that has really pained me in the switch from Rails to Django. Though I totally understand, since Rails doesn't enforce foreign key constraints in the DB layer (or really do anything complex with the database at all) and obviously model introspection in Django is a much harder problem than the Rails migration functionality. Anyways, Its great to see that this is moving forward and hopefully getting into core someday in the future. Thanks Again! ~Jamie On Nov 27, 3:40 pm, Mike H <[EMAIL PROTECTED]> wrote: > SmileyChris wrote: > > On Nov 26, 1:03 pm, LorenDavie <[EMAIL PROTECTED]> wrote: > > >> Not sure if SmileyChris is this guy, but I've had good success with > >> this project: > > >>http://www.aswmc.com/dbmigration/ > > > As Mike H said, dbmigration is his project (my DBEvolution project did > > some of the "automatically generated migrations" magic using > > dbmigration as its base). > > > If you like how dbmigration works, you'll probably like Django > > Evolution. > > I do! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
SmileyChris wrote: > On Nov 26, 1:03 pm, LorenDavie <[EMAIL PROTECTED]> wrote: > >> Not sure if SmileyChris is this guy, but I've had good success with >> this project: >> >> http://www.aswmc.com/dbmigration/ >> > > As Mike H said, dbmigration is his project (my DBEvolution project did > some of the "automatically generated migrations" magic using > dbmigration as its base). > > If you like how dbmigration works, you'll probably like Django > Evolution. > I do! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
On Nov 26, 1:03 pm, LorenDavie <[EMAIL PROTECTED]> wrote: > Not sure if SmileyChris is this guy, but I've had good success with > this project: > > http://www.aswmc.com/dbmigration/ As Mike H said, dbmigration is his project (my DBEvolution project did some of the "automatically generated migrations" magic using dbmigration as its base). If you like how dbmigration works, you'll probably like Django Evolution. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
On 11/27/07, Massimiliano Ravelli <[EMAIL PROTECTED]> wrote: > > On 25 Nov, 10:21, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > What is the recommended method to do this right now, what are you all > > using, just plain SQL? Basically, I'm looking for the best solution to > > this problem and would like to know what the community recommends. > > I can't raccomand you any of these but I can say that, after > a long waiting, I found the project *I* like and fits *my* needs: > Django Evolution. > > Here's some point about django evolution: > - good documentation > - clean and elegant (like django ;-) ) > - works with a recent version of trunk > - intergrates with django management without patching it > (thanks to the recent version of django itself) > - I can avoid to add information about evolution to my models > - helps to track and apply changes to the database. Thanks for the compliments. I'm glad Django Evolution meets your needs. > I know: it can handle automatically only few case. > It doesn't support DeleteModel mutation... but I don't care: > I know a bit of sql and I can write a "DROP TABLE" statement. ;-) FYI - DE will support DeleteModel very soon. There is a prototype implementation attached to ticket #12; this patch requires a few minor tweaks before it is committed, but with any luck, I'll get a chance to put some time into this very soon. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
On 25 Nov, 10:21, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > What is the recommended method to do this right now, what are you all > using, just plain SQL? Basically, I'm looking for the best solution to > this problem and would like to know what the community recommends. I can't raccomand you any of these but I can say that, after a long waiting, I found the project *I* like and fits *my* needs: Django Evolution. Here's some point about django evolution: - good documentation - clean and elegant (like django ;-) ) - works with a recent version of trunk - intergrates with django management without patching it (thanks to the recent version of django itself) - I can avoid to add information about evolution to my models - helps to track and apply changes to the database. I know: it can handle automatically only few case. It doesn't support DeleteModel mutation... but I don't care: I know a bit of sql and I can write a "DROP TABLE" statement. ;-) I read the documentation of all these projects to make my choice. As it doesn't take to much time, I advise you to do the same to chose the project that better fits your needs. Regards Massimiliano --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
the SoC2006 branch isn't dead (assuming that's what you're talking about not being touched in 4 months), it has just been pulled into an external project: http://code.google.com/p/deseb/ there is also an intro/howto video available here: http://kered.org/deseb_demo.mpeg ~10 minutes. the audio quality sucks, (i'm no AV guy), but it gives you a good overview. :) derek [EMAIL PROTECTED] wrote: > I'm aware of a number of different schema evolution (Rails style > migration) tools that exist, most notably the ones listed at > http://code.djangoproject.com/wiki/SchemaEvolution > > While there seems to be two branches dealing with schema evolution one > doesn't seem to have been touched in 4 months, and the other in 11. > What is the recommended method to do this right now, what are you all > using, just plain SQL? Basically, I'm looking for the best solution to > this problem and would like to know what the community recommends. > > Best, > Jamie > > > > -- looking to buy or sell anything? try: http://allurstuff.com it's a classified ads service that shows on a map where the seller is (think craigslist + google maps) plus it's 100% free :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
That one is me. It's intended as a stop-gap until a more pythonic, as you say, evolution tool is officially working. Due to the complexity of automatically generating migrations and the amount of time I have to spend on it, the dbmigration tool will only ever be a way of automatically applying sql or python migrations that you write yourself. Thanks to a couple of contributors, I should have a version working for the SVN trunk quite soon (it's in the final stages of testing). Cheers, MikeH LorenDavie wrote: > Not sure if SmileyChris is this guy, but I've had good success with > this project: > > http://www.aswmc.com/dbmigration/ > > I use it (with postgres) and it works just fine for me. It would be > nice if it was a bit more "pythonic", but it definitely gets the job > done. > > On Nov 25, 6:43 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > >> On Nov 25, 2007 6:21 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> >> >> >>> I'm aware of a number of different schema evolution (Rails style >>> migration) tools that exist, most notably the ones listed at >>> http://code.djangoproject.com/wiki/SchemaEvolution >>> >>> While there seems to be two branches dealing with schema evolution one >>> doesn't seem to have been touched in 4 months, and the other in 11. >>> What is the recommended method to do this right now, what are you all >>> using, just plain SQL? Basically, I'm looking for the best solution to >>> this problem and would like to know what the community recommends. >>> >> Caveat - I'm one of the developers of Django Evolution, mentioned below. >> >> Regarding the two schema-evolution branches: they are no longer being >> maintained in the Django source tree. >> >> The original branch was a Google Summer of Code 2006 project. This >> project wasn't fully completed at the time; Derek (the person working >> on the branch) revisited the code earlier this year with a view to >> finishing the project. However, the design he produced wasn't >> satisfactory to the core developers (in particular, myself, but backed >> up by others). Derek disagreed, and so he used his design and code as >> the starting point for the DESEB project on Google code. >> >> The second branch was created, and then immediately went nowhere. The >> user that requested the branch disappeared almost as soon as the >> branch was created. >> >> So - what is the recommended solution? Well, there's no official >> recommendation. >> >> If I were a betting man, I would say Django Evolution has the best >> chance of eventually becoming the official migration mechanism for >> Django. A few high profile Django users have made favourable noises >> about the approach taken by Django Evolution. However, Django >> Evolution is still under relatively early development; certain >> migrations work well, others aren't implemented at all. Depending on >> your exact needs, and your willingness to work around/with any bugs >> that may still exist, it may be enough for you. Check out the FAQ and >> ticket tracker for the project if you want more details. >> >> You may also get some milage out of DESEB; however, I wouldn't >> recommend it personally. If you want to know more about my concerns, >> hunt down the threads on the Django Developers list that deal with the >> schema-evolution branch. >> >> SmileyChris was working on an alternative called DB Evolution >> alternative a while back; however, he is now contributing to Django >> Evolution. >> >> I can't make any comment on YADSEL, schema-evolution and >> django-schemaevolution. I remember the announcement of YADSEL and >> django-schemaevolution, but I can't say I've heard anything from them >> since. YMMV. >> >> Based on the current state of play, it will be a long time before any >> merge happens, and it isn't guaraneed that a merge will ever happen. >> Writing the ALTER TABLE statements yourself is the only method that is >> guaranteed to be feature complete and bug free at present. >> >> Yours, >> Russ Magee %-) >> > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
The other "schema-evolution-ng" code is very dead. I don't have time to maintain patches against Django anymore, and the patches I no longer even use my own schema evolution code - it's fallen far out of sync with Django's SVN head. FYI - it basically just did what Derek's schema evolution code was supposed to do when the original SoC project was completed, but that ends up not being sufficiently powerful for non-trivial schema modifications. Can someone delete that branch? vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
Not sure if SmileyChris is this guy, but I've had good success with this project: http://www.aswmc.com/dbmigration/ I use it (with postgres) and it works just fine for me. It would be nice if it was a bit more "pythonic", but it definitely gets the job done. On Nov 25, 6:43 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Nov 25, 2007 6:21 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > I'm aware of a number of different schema evolution (Rails style > > migration) tools that exist, most notably the ones listed at > >http://code.djangoproject.com/wiki/SchemaEvolution > > > While there seems to be two branches dealing with schema evolution one > > doesn't seem to have been touched in 4 months, and the other in 11. > > What is the recommended method to do this right now, what are you all > > using, just plain SQL? Basically, I'm looking for the best solution to > > this problem and would like to know what the community recommends. > > Caveat - I'm one of the developers of Django Evolution, mentioned below. > > Regarding the two schema-evolution branches: they are no longer being > maintained in the Django source tree. > > The original branch was a Google Summer of Code 2006 project. This > project wasn't fully completed at the time; Derek (the person working > on the branch) revisited the code earlier this year with a view to > finishing the project. However, the design he produced wasn't > satisfactory to the core developers (in particular, myself, but backed > up by others). Derek disagreed, and so he used his design and code as > the starting point for the DESEB project on Google code. > > The second branch was created, and then immediately went nowhere. The > user that requested the branch disappeared almost as soon as the > branch was created. > > So - what is the recommended solution? Well, there's no official > recommendation. > > If I were a betting man, I would say Django Evolution has the best > chance of eventually becoming the official migration mechanism for > Django. A few high profile Django users have made favourable noises > about the approach taken by Django Evolution. However, Django > Evolution is still under relatively early development; certain > migrations work well, others aren't implemented at all. Depending on > your exact needs, and your willingness to work around/with any bugs > that may still exist, it may be enough for you. Check out the FAQ and > ticket tracker for the project if you want more details. > > You may also get some milage out of DESEB; however, I wouldn't > recommend it personally. If you want to know more about my concerns, > hunt down the threads on the Django Developers list that deal with the > schema-evolution branch. > > SmileyChris was working on an alternative called DB Evolution > alternative a while back; however, he is now contributing to Django > Evolution. > > I can't make any comment on YADSEL, schema-evolution and > django-schemaevolution. I remember the announcement of YADSEL and > django-schemaevolution, but I can't say I've heard anything from them > since. YMMV. > > Based on the current state of play, it will be a long time before any > merge happens, and it isn't guaraneed that a merge will ever happen. > Writing the ALTER TABLE statements yourself is the only method that is > guaranteed to be feature complete and bug free at present. > > Yours, > Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Preferred Schema Evolution Tool
On Nov 25, 2007 6:21 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I'm aware of a number of different schema evolution (Rails style > migration) tools that exist, most notably the ones listed at > http://code.djangoproject.com/wiki/SchemaEvolution > > While there seems to be two branches dealing with schema evolution one > doesn't seem to have been touched in 4 months, and the other in 11. > What is the recommended method to do this right now, what are you all > using, just plain SQL? Basically, I'm looking for the best solution to > this problem and would like to know what the community recommends. Caveat - I'm one of the developers of Django Evolution, mentioned below. Regarding the two schema-evolution branches: they are no longer being maintained in the Django source tree. The original branch was a Google Summer of Code 2006 project. This project wasn't fully completed at the time; Derek (the person working on the branch) revisited the code earlier this year with a view to finishing the project. However, the design he produced wasn't satisfactory to the core developers (in particular, myself, but backed up by others). Derek disagreed, and so he used his design and code as the starting point for the DESEB project on Google code. The second branch was created, and then immediately went nowhere. The user that requested the branch disappeared almost as soon as the branch was created. So - what is the recommended solution? Well, there's no official recommendation. If I were a betting man, I would say Django Evolution has the best chance of eventually becoming the official migration mechanism for Django. A few high profile Django users have made favourable noises about the approach taken by Django Evolution. However, Django Evolution is still under relatively early development; certain migrations work well, others aren't implemented at all. Depending on your exact needs, and your willingness to work around/with any bugs that may still exist, it may be enough for you. Check out the FAQ and ticket tracker for the project if you want more details. You may also get some milage out of DESEB; however, I wouldn't recommend it personally. If you want to know more about my concerns, hunt down the threads on the Django Developers list that deal with the schema-evolution branch. SmileyChris was working on an alternative called DB Evolution alternative a while back; however, he is now contributing to Django Evolution. I can't make any comment on YADSEL, schema-evolution and django-schemaevolution. I remember the announcement of YADSEL and django-schemaevolution, but I can't say I've heard anything from them since. YMMV. Based on the current state of play, it will be a long time before any merge happens, and it isn't guaraneed that a merge will ever happen. Writing the ALTER TABLE statements yourself is the only method that is guaranteed to be feature complete and bug free at present. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Preferred Schema Evolution Tool
I'm aware of a number of different schema evolution (Rails style migration) tools that exist, most notably the ones listed at http://code.djangoproject.com/wiki/SchemaEvolution While there seems to be two branches dealing with schema evolution one doesn't seem to have been touched in 4 months, and the other in 11. What is the recommended method to do this right now, what are you all using, just plain SQL? Basically, I'm looking for the best solution to this problem and would like to know what the community recommends. Best, Jamie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
schema evolution [testers wanted]
hey all,
i have finished writing unit tests covering the mysql, postgresql and
sqlite3 backends, as well as notably expanding what
introspections/migrations the sqlite3 backend can handle. also, full
documentation (including installation and usage instructions) is
available both in the branch and here:
http://code.djangoproject.com/wiki/SchemaEvolutionDocumentation
additionally, the latest changes from the trunk (r5787) have been merged
into the schema-evolution branch, so you won't lose any recent updates
by giving it a shot.
obviously, this is an area with a lot of corner cases. if you can,
please give it a shot ("./manage sqlevolve app_name" after you've made a
model change) and send me whatever bugs you find [EMAIL PROTECTED]
please include if you can:
* which database you're using
* your models.py file
* your previous models.py and/or your existing database schema
thanks!
derek anderson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: schema evolution
this is the right place. or anyone can feel free to PM me. which database are you using? can you give me a copy of your model file and a dump of your existing schema? Romo wrote: > Hello! > > I don't know if this is the right place to a little problem I have > with this... > > I installed schema-evolution and everything seemed to be fine... when > i try to run it with: > > python manage.py sqlevolve app_name (obviously app_name is not my app > name :P) > > I get the following: > > BEGIN; > Traceback (most recent call last): > File "manage.py", line 11, in ? > execute_manager(settings) > File "/usr/lib/python2.4/site-packages/django/core/management.py", > line 1898, in execute_manager > execute_from_command_line(action_mapping, argv) > File "/usr/lib/python2.4/site-packages/django/core/management.py", > line 1858, in execute_from_command_line > output = action_mapping[action](mod) > File "/usr/lib/python2.4/site-packages/django/core/management.py", > line 519, in get_sql_evolution > output = get_sql_evolution_check_for_changed_field_flags(klass, > new_table_name) > File "/usr/lib/python2.4/site-packages/django/core/management.py", > line 627, in get_sql_evolution_check_for_changed_field_flags > existing_fields = introspection.get_columns(cursor,db_table) > AttributeError: 'module' object has no attribute 'get_columns' > > I've got django .96 > > Cheers > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
Hello! I don't know if this is the right place to a little problem I have with this... I installed schema-evolution and everything seemed to be fine... when i try to run it with: python manage.py sqlevolve app_name (obviously app_name is not my app name :P) I get the following: BEGIN; Traceback (most recent call last): File "manage.py", line 11, in ? execute_manager(settings) File "/usr/lib/python2.4/site-packages/django/core/management.py", line 1898, in execute_manager execute_from_command_line(action_mapping, argv) File "/usr/lib/python2.4/site-packages/django/core/management.py", line 1858, in execute_from_command_line output = action_mapping[action](mod) File "/usr/lib/python2.4/site-packages/django/core/management.py", line 519, in get_sql_evolution output = get_sql_evolution_check_for_changed_field_flags(klass, new_table_name) File "/usr/lib/python2.4/site-packages/django/core/management.py", line 627, in get_sql_evolution_check_for_changed_field_flags existing_fields = introspection.get_columns(cursor,db_table) AttributeError: 'module' object has no attribute 'get_columns' I've got django .96 Cheers --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
added postgres unit tests to the schema-evolution branch. also fixed a bug where constraint lookups in postgres broke after a model rename. thanks, derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
Russell Keith-Magee wrote: > Documentation should be about how to use a feature, not how the > internals of a feature work. fixed in the branch. plus it now includes installation instructions, a future work section, etc. also available here: http://code.djangoproject.com/wiki/SchemaEvolutionDocumentation > However, reading between the lines, here are a few quick comments: > > - The introspection stuff is neat, but I _really_ don't like the aka > representations in the model. The models file should always be a clean > statement of the current state of the model. Migration is about > getting an old database to match the currently required models - if I > don't have a legacy database, I don't really want the cruft hanging > around in my models. Migration plans or historical models really > should be kept out of the core model file, IMHO. We currently store all sorts of non-DB related metadata in the model that arguably should not be there, including presentation information. We do this for clarity and convenience - you would have to duplicate a lot of information otherwise in multiple locations without any obvious direct connection. So which paradigm is more critical here, DRY or MVC? Or do we continue with the status-quo of finding a common-sense balance? As far as cruft, if you don't have a legacy database, you wouldn't have any aka fields to begin with. And as you phase out legacy support, simply delete them. > - Unless I'm missing something, the aka approach doesn't track exactly > which name versions correlate with other versions. Consider; your aka > chain for one field could indicate a rename from 'foo' to 'bar' to > 'foo' to 'bar'; a second field could indicate renames from 'whiz' to > 'foo' to 'whiz', etc. A tuple of historical names doesn't tell me > which sets of names were in use concurrently; so if I find a database > with a field called 'foo' which requires migration, is 'foo' the first > field or the second? Correct, however I thought this to be a highly unlikely scenario, not warranting the extra notational complexity. But just as we support strings and tuples, there is nothing to say we can extend it to support say, a mapping of historical names to date ranges or version numbers, if the need arises. > - Your patch doesn't seem to address issue of cross-platform SQL. [...] > I can't see anything in your code that provides an alternate mechanism > for removing columns, or providing a warning if you try to remove a > column from an SQLite table. db-specific issues are handled in the backend, behind the api interface used by all the backends. for your example, deleting a column in sqlite generates the following warning: -- FYI: sqlite does not support deleting columns, so 'col_name' remains as cruft > - Your patch doesn't seem to address the issue of sequential evolution > - changes that must be applied sequentially (rather than just > adding/removing columns to get you from current database state to > current model definition). This is particularly relevant when you > start looking at doing data conversion as part of the migration > process we do handle at least some sequential changes. for example: renaming a column while you're renaming the table it's in. and in the future work section i talk about how data conversion would work, but that wouldn't require any user-visible changes and doesn't impede the current functionality. give me some scenarios for where you're concerned. > I don't see how you can test schema-evolution without reloading > models. The tests you have are useful - they demonstrate that the > right SQL is generated - but this doesn't help if the SQL can change > on a per-backend basis. i agree, this is needed. if anyone knows how to add a field to an already-loaded class in python, please send me a link to the process. i could find adding methods, but not fields. also, yes, currently only the MYSQL backend is tested. postgres and sqlite tests are coming... (and yes, the sql does change on a per-backend basis) > SQL generation is also the least complex part of the entire process. > Your tests don't check that complex part - the introspection is being > done correctly. There is no use in generating the correct SQL for a > rename if you can't identify what constitutes a rename :-) look closer - the introspection is being called and tested in each of the examples. (i'm not just calling the sql-generation methods) but i do admit that the tests are not comprehensive. i figure release early/often. :) > Yours, > Russ Magee %-) glad for the constructive criticism. :) i think the only thing we're
Re: schema evolution
On 7/31/07, Derek Anderson <[EMAIL PROTECTED]> wrote: > testing and documentation (plus two minor bug fixes) are checked into > the schema-evolution branch: > > tests/modeltests/schema_evolution/models.py > docs/schema-evolution.txt Documentation should be about how to use a feature, not how the internals of a feature work. These docs are great for showing what SQL will be generated - but they aren't much help to the end user. They don't answer the questions "how do I start the migration process? What do I need to define to make a migration happen?" Read the original wiki proposal again - how does this documentation help Alice? However, reading between the lines, here are a few quick comments: - The introspection stuff is neat, but I _really_ don't like the aka representations in the model. The models file should always be a clean statement of the current state of the model. Migration is about getting an old database to match the currently required models - if I don't have a legacy database, I don't really want the cruft hanging around in my models. Migration plans or historical models really should be kept out of the core model file, IMHO. - Unless I'm missing something, the aka approach doesn't track exactly which name versions correlate with other versions. Consider; your aka chain for one field could indicate a rename from 'foo' to 'bar' to 'foo' to 'bar'; a second field could indicate renames from 'whiz' to 'foo' to 'whiz', etc. A tuple of historical names doesn't tell me which sets of names were in use concurrently; so if I find a database with a field called 'foo' which requires migration, is 'foo' the first field or the second? - Your patch doesn't seem to address issue of cross-platform SQL. I know of at least one major cross platform problem - quoting the SQLite docs: "SQLite's version of the ALTER TABLE command allows the user to rename or add a new column to an existing table. It is not possible to remove a column from a table." I can't see anything in your code that provides an alternate mechanism for removing columns, or providing a warning if you try to remove a column from an SQLite table. - Your patch doesn't seem to address the issue of sequential evolution - changes that must be applied sequentially (rather than just adding/removing columns to get you from current database state to current model definition). This is particularly relevant when you start looking at doing data conversion as part of the migration process - Speaking of which - how does data migration fit into this model? > > because I suspect the existing test framework will require some > > modifications to enable models to be evolved during a test run. > > yeah, i spent some time trying to figure out how i could load a model, > change it, then run the evolve introspection scripts. but in the end, i > just wrote sql to simulate what the model used to look like. i figured > low-impact==good. (but i'm open to different ideas) I don't see how you can test schema-evolution without reloading models. The tests you have are useful - they demonstrate that the right SQL is generated - but this doesn't help if the SQL can change on a per-backend basis. SQL generation is also the least complex part of the entire process. Your tests don't check that complex part - the introspection is being done correctly. There is no use in generating the correct SQL for a rename if you can't identify what constitutes a rename :-) Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
testing and documentation (plus two minor bug fixes) are checked into the schema-evolution branch: tests/modeltests/schema_evolution/models.py docs/schema-evolution.txt > because I suspect the existing test framework will require some > modifications to enable models to be evolved during a test run. yeah, i spent some time trying to figure out how i could load a model, change it, then run the evolve introspection scripts. but in the end, i just wrote sql to simulate what the model used to look like. i figured low-impact==good. (but i'm open to different ideas) derek Russell Keith-Magee wrote: > On 7/20/07, Derek Anderson <[EMAIL PROTECTED]> wrote: >> but i use django >> quite a bit now and am surprised some sort of this hasn't been merged >> yet, so i figured i'd bring it up to date and re-release. > > By casting a quick eye over the patch, I caught at least two reasons > that this hasn't been merged (or taken particularly seriously by the > core developers): > > - No tests. > - No documentation. > > I agree that schema evolution would be a valuable addition to Django. > However, if you (or anyone else) is serious about getting this into > trunk, adding a comprehensive test suite and draft documentation is a > non-negotiable prerequisite for . > > The testing requirement is especially relevant for schema-evolution > because I suspect the existing test framework will require some > modifications to enable models to be evolved during a test run. If you > want to prove to me that you are serious, show me the tests. > > Yours, > Russ Magee %-) > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
understandable. i do have both, but not integrated into django's framework. when i finish such, would you suggest a patch posted to the list, or attached to a bug report? (if the latter, a new bug or is there a schema evolution bug already in discussion?) danke, derek Russell Keith-Magee wrote: > On 7/20/07, Derek Anderson <[EMAIL PROTECTED]> wrote: >> but i use django >> quite a bit now and am surprised some sort of this hasn't been merged >> yet, so i figured i'd bring it up to date and re-release. > > By casting a quick eye over the patch, I caught at least two reasons > that this hasn't been merged (or taken particularly seriously by the > core developers): > > - No tests. > - No documentation. > > I agree that schema evolution would be a valuable addition to Django. > However, if you (or anyone else) is serious about getting this into > trunk, adding a comprehensive test suite and draft documentation is a > non-negotiable prerequisite for . > > The testing requirement is especially relevant for schema-evolution > because I suspect the existing test framework will require some > modifications to enable models to be evolved during a test run. If you > want to prove to me that you are serious, show me the tests. > > Yours, > Russ Magee %-) > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
On 7/20/07, Derek Anderson <[EMAIL PROTECTED]> wrote: > > but i use django > quite a bit now and am surprised some sort of this hasn't been merged > yet, so i figured i'd bring it up to date and re-release. By casting a quick eye over the patch, I caught at least two reasons that this hasn't been merged (or taken particularly seriously by the core developers): - No tests. - No documentation. I agree that schema evolution would be a valuable addition to Django. However, if you (or anyone else) is serious about getting this into trunk, adding a comprehensive test suite and draft documentation is a non-negotiable prerequisite for . The testing requirement is especially relevant for schema-evolution because I suspect the existing test framework will require some modifications to enable models to be evolved during a test run. If you want to prove to me that you are serious, show me the tests. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
Hey all, Sorry for the double-post, but I've written up some examples / documentation: http://kered.org/blog/wp-content/uploads/2007/07/django_schema_evolution_documentation.html Also, I've ported the changes to SVN. I would like to solicit testers, for potential inclusion in django-proper. Thanks, Derek Derek Anderson wrote: > Hey all, > > I've ported my schema evolution work from my SoC project last summer to > Django v0.96. To use it, download the patch below, and run the following: > > $ cd //site-packages/django/ > $ patch -p1 < ~//django_schema_evolution-v096patch.txt > > It should output the following: > > patching file core/management.py > patching file db/backends/mysql/base.py > patching file db/backends/mysql/introspection.py > patching file db/backends/postgresql/base.py > patching file db/backends/postgresql/introspection.py > patching file db/backends/sqlite3/base.py > patching file db/backends/sqlite3/introspection.py > patching file db/models/fields/__init__.py > patching file db/models/options.py > > To use it: > > $ cd // > $ ./manage.py sqlevolve > > It should output something like this: > > BEGIN; > ALTER TABLE `main_query` CHANGE COLUMN `accuracy` `accuracynew` > numeric(10, 6) NULL; > ALTER TABLE `main_query` ADD COLUMN `price` varchar(256) NULL; > COMMIT; > > Assuming you have a model such as this: > > class Query(models.Model): > query = models.CharField(maxlength=256, blank=False) > accuracynew = models.FloatField(max_digits=10, decimal_places=6, > null=True, blank=True, aka='accuracy') > price = models.CharField(maxlength=256, null=True, blank=True) # > new column > > Note the aka field where I changed the name of "accuracy" to "accuracynew". > > Let me know if you find any bugs. > > http://kered.org/blog/2007-07-19/django-schema-evolution/ > http://kered.org/blog/wp-content/uploads/2007/07/django_schema_evolution-v096patch.txt > > -- Derek > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
yeah, i did a poor/non-existent job advocating inclusion of my SoC work into django-proper. (combination of frustration with my original mentor and busy prepping for starting my phd right after it ended - i just handed it off and didn't follow through afterwards) but i use django quite a bit now and am surprised some sort of this hasn't been merged yet, so i figured i'd bring it up to date and re-release. daev wrote: > It's great! I have my own schema evolution solution here > http://code.google.com/p/django-schemaevolution/. But yours seems to > be more powerful. > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: schema evolution
It's great! I have my own schema evolution solution here http://code.google.com/p/django-schemaevolution/. But yours seems to be more powerful. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
schema evolution
Hey all, I've ported my schema evolution work from my SoC project last summer to Django v0.96. To use it, download the patch below, and run the following: $ cd //site-packages/django/ $ patch -p1 < ~//django_schema_evolution-v096patch.txt It should output the following: patching file core/management.py patching file db/backends/mysql/base.py patching file db/backends/mysql/introspection.py patching file db/backends/postgresql/base.py patching file db/backends/postgresql/introspection.py patching file db/backends/sqlite3/base.py patching file db/backends/sqlite3/introspection.py patching file db/models/fields/__init__.py patching file db/models/options.py To use it: $ cd // $ ./manage.py sqlevolve It should output something like this: BEGIN; ALTER TABLE `main_query` CHANGE COLUMN `accuracy` `accuracynew` numeric(10, 6) NULL; ALTER TABLE `main_query` ADD COLUMN `price` varchar(256) NULL; COMMIT; Assuming you have a model such as this: class Query(models.Model): query = models.CharField(maxlength=256, blank=False) accuracynew = models.FloatField(max_digits=10, decimal_places=6, null=True, blank=True, aka='accuracy') price = models.CharField(maxlength=256, null=True, blank=True) # new column Note the aka field where I changed the name of "accuracy" to "accuracynew". Let me know if you find any bugs. http://kered.org/blog/2007-07-19/django-schema-evolution/ http://kered.org/blog/wp-content/uploads/2007/07/django_schema_evolution-v096patch.txt -- Derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Schema evolution
Hi all, Does anyone know what the plans for the schema evolution branch are? Can we expect to see its ideas and code in 1.0? I ask as having to write a patch runner to update live schemas is the only part of working with Django that is an annoyance :) Mike --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Query regarding Schema evolution branch.
Hi, I am writing an app where I will occasionally need to change my db schema. I am not an SQL expert, and would like to confine myself to python and django db APIs if possible (don't want to go through raw SQL or db engine specific code). After some googling I found django's schema evolution branch that seems to be created for this. I am having a look at this branch, but don't have a clue as to how to use it for migrating my db from one schema to another. I would like to know- 1. How stable this branch is 2. Has anyone used/is using this branch for any app 3. If this branch can be used for db migration, some guide or examples towards that. I know a fair amount of python, so if required can contribute towards this. Regards, Ram --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ForeignKey, null, and schema evolution
"Ramiro Morales" <[EMAIL PROTECTED]> writes:
> On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>>
>> Whatever django bugs may be lurking asid, I need to move forward with
>> my project ASAP so I'd really appreciate it if someone could give me a
>> few hints about how to evolve my existing DB (which was created
>> without the primary_key=True and (I think) also without null=True) so
>> I can still use the data.
>
> Disclamer: I know almost nothing about databases.
>
> Oh, this is a (new) hint. You are not sure if you created your data
> when the Session -> Track ForeignKey had null=True? If it hadn' t
> and you are now trying to modify it it to use that option without
> also modifying the DB, it's not that strange you are getting errors.
Yes, I'm aware of that. That's why I asked for help evolving the DB.
> You could confirm that by examining the table stucture. Use:
>
> $ ./manage.py sql program
>
> twice, once without null=True and once with null=True, to see the difference
> and eventually create the ALTER TABLE SQL sentence to modify to reflect
> the change you' ve made to your model without losing your valuable data.
Good trick, thanks.
> This is using sqlite3:
>
> --- nonull.txt 2007-02-10 19:29:23.0 -0300
> +++ nulltrue.txt2007-02-10 19:28:48.0 -0300
> @@ -13,13 +13,13 @@
> CREATE TABLE "program_session" (
> "id" integer NOT NULL PRIMARY KEY,
> "title" varchar(200) NOT NULL,
> "short_title" varchar(50) NOT NULL,
> "description" text NOT NULL,
> "start_id" integer NOT NULL REFERENCES "program_timedivision" ("id"),
> -"track_id" integer NOT NULL REFERENCES "program_track" ("id"),
> +"track_id" integer NULL REFERENCES "program_track" ("id"),
> "duration" time NOT NULL,
> UNIQUE ("start_id", "track_id"),
> UNIQUE ("title")
> );
> CREATE TABLE "program_speaker" (
> "id" integer NOT NULL PRIMARY KEY,
Super; thanks for your help!
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: ForeignKey, null, and schema evolution
On 2/10/07, David Abrahams <[EMAIL PROTECTED]> wrote:
>
> Whatever django bugs may be lurking asid, I need to move forward with
> my project ASAP so I'd really appreciate it if someone could give me a
> few hints about how to evolve my existing DB (which was created
> without the primary_key=True and (I think) also without null=True) so
> I can still use the data.
Disclamer: I know almost nothing about databases.
Oh, this is a (new) hint. You are not sure if you created your data when
the Session -> Track ForeignKey had null=True? If it hadn' t and you are
now trying to modify it it to use that option without also modifying the DB,
it's not that strange you are getting errors.
You could confirm that by examining the table stucture. Use:
$ ./manage.py sql program
twice, once without null=True and once with null=True, to see the difference
and eventually create the ALTER TABLE SQL sentence to modify to reflect
the change you' ve made to your model without losing your valuable data.
This is using sqlite3:
--- nonull.txt 2007-02-10 19:29:23.0 -0300
+++ nulltrue.txt2007-02-10 19:28:48.0 -0300
@@ -13,13 +13,13 @@
CREATE TABLE "program_session" (
"id" integer NOT NULL PRIMARY KEY,
"title" varchar(200) NOT NULL,
"short_title" varchar(50) NOT NULL,
"description" text NOT NULL,
"start_id" integer NOT NULL REFERENCES "program_timedivision" ("id"),
-"track_id" integer NOT NULL REFERENCES "program_track" ("id"),
+"track_id" integer NULL REFERENCES "program_track" ("id"),
"duration" time NOT NULL,
UNIQUE ("start_id", "track_id"),
UNIQUE ("title")
);
CREATE TABLE "program_speaker" (
"id" integer NOT NULL PRIMARY KEY,
Regards,
--
Ramiro Morales
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: ForeignKey, null, and schema evolution
"yary" <[EMAIL PROTECTED]> writes: > IIRC, Django's admin can't handle a field with null=True and > blank=False (which is a bit of a shame...) Try adding blank=True to > your model's field? Read my latest post and you'll see that I have tried that. It works, but only if I explicitly specify the ForeignKey's primary key. -- Dave Abrahams Boost Consulting www.boost-consulting.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ForeignKey, null, and schema evolution
IIRC, Django's admin can't handle a field with null=True and blank=False (which is a bit of a shame...) Try adding blank=True to your model's field? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ForeignKey, null, and schema evolution
David Abrahams <[EMAIL PROTECTED]> writes: > My models.py is enclosed. It doesn't have any special dependencies. > Would you mind trying to reproduce the problem? > >> Try creating a smaller project with a trimmed >> down model -- doing the standard "remove stuff until it starts working >> or you are only left with the ForeignKey" process. > > I'll see if I can do that. FYI, I can reproduce two problems in a smaller complete project (enclosed), although I haven't had success creating a minimal case. Steps to reproduce the main problem: 0. create a database 1. syncdb 2. run the dev server 3. go to http://localhost:8000/admin/ and login 4. create a new Session object 5. fill in all required fields, creating a Speaker and TimeDivision as needed. leave Track as '--' 6. Save How to make it work: 7. Set primary_key=True on the 'name' field of the Track object 8. AND add blank=True to the 'track' field of the Session object 9. delete the database 10. repeat Note that without blank=True, the Session with no track won't validate. Whatever django bugs may be lurking asid, I need to move forward with my project ASAP so I'd really appreciate it if someone could give me a few hints about how to evolve my existing DB (which was created without the primary_key=True and (I think) also without null=True) so I can still use the data. Thanks, --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~--- djtest.tar.bz2 Description: Binary data -- Dave Abrahams Boost Consulting www.boost-consulting.com
Re: ForeignKey, null, and schema evolution
Malcolm Tredinnick <[EMAIL PROTECTED]> writes:
> On Sat, 2007-02-10 at 03:34 -0500, David Abrahams wrote:
>>
>> In my attempt to use
>>
>>ForeignKey(Track, null=True)
>>
>> When I actually tried to use a null Track value, I got:
> [...traceback snipped...]
>>
>> ProgrammingError at /admin/program/session/15/
>> ERROR: invalid input syntax for integer: "" SELECT
>> "program_session"."id","program_session"."title","program_session"."short_title","program_session"."description","program_session"."start_id","program_session"."track_id","program_session"."duration"
>> FROM "program_session" INNER JOIN "program_timedivision" AS
>> "program_session__start" ON "program_session"."start_id" =
>> "program_session__start"."id" WHERE ("program_session__start"."id" ILIKE
>> '40' AND "program_session"."track_id" = '')
>>
>> My wild guess here is that this happens because track_id is the primary key
>> and thus expects an integer value; had I made the track name its
>> primary key it might've worked (?). Anyway, if I want to make that
>> change at this point, I don't know how to do so without losing my
>> valuable data. Any help you can offer me would be very much
>> appreciated.
>
> Can you give a little more information about how you triggered this
> error? It looks like you are doing something in the admin,
I am. I'm saving an existing Session object after setting its Track
to the "--" entry in the pop-up used for track selection. I get
a similar effect when creating a new Session without setting the
Track.
> but I am using null=True foreign keys through the admin successfully
> without doing anything special, so it's not totally impossible. It
> shows up fine in the admin system and the database stores the
> reference as a NULL (in my case). And I'm using PostgreSQL, too, so
> it's not a db-specific thing that I can see (although I'm using
> psycopg1, not psycopg2).
>
> If you triggered the problem just by trying to add a record in the admin
> and leaving the "track" reference field empty, it's going to be a little
> hard to debug remotely.
My models.py is enclosed. It doesn't have any special dependencies.
Would you mind trying to reproduce the problem?
> Try creating a smaller project with a trimmed
> down model -- doing the standard "remove stuff until it starts working
> or you are only left with the ForeignKey" process.
I'll see if I can do that.
> I can't place what portion of the admin is generating the query you are
> seeing, so any information you can provide would be useful.
The endlosed models.py ought to be sufficient.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
from django.db import models
class Speaker(models.Model):
last_name = models.CharField(maxlength=100)
first_name = models.CharField(maxlength=100)
email = models.EmailField()
bio = models.TextField()
class Meta:
ordering = ('last_name','first_name','email')
class Admin:
pass
# list_display = ('first_name', 'last_name')
def __str__(self):
return self.first_name + ' ' + self.last_name
class Track(models.Model):
name = models.CharField(maxlength=100, primary_key=True)
description = models.TextField()
class Admin:
list_display = ('name', 'description')
def __str__(self):
return self.name
class TimeDivision(models.Model):
when = models.DateTimeField()
starts_break = models.BooleanField()
name = models.CharField(maxlength=100)
class Admin:
pass
# list_display = ('name', 'when', 'starts_break')
class Meta:
ordering = ('when',)
def __str__(self):
return self.when.strftime('%A') + ' ' + self.name
class Session(models.Model):
title = models.CharField(maxlength=200)
speakers = models.ManyToManyField(Speaker, filter_interface =
models.HORIZONTAL, related_name='Sessions')
short_title = models.CharField(maxlength=50,blank=True)
description = models.TextField()
start = models.ForeignKey(TimeDivision)
track = models.ForeignKey(Track,blank=True,null=True)
duration = models.TimeField()
def __str__(self):
return ', '.join([s.last_name for s in self.speakers.all()]) \
+ ': ' + (self.short_title or self.title)
class Admin:
pass
class Meta:
# These constraints are imperfect but should catch many common errors
unique_together = (
('start','track'), # only one session may start in a given
Re: ForeignKey, null, and schema evolution
On Sat, 2007-02-10 at 03:34 -0500, David Abrahams wrote:
>
> In my attempt to use
>
>ForeignKey(Track, null=True)
>
> When I actually tried to use a null Track value, I got:
[...traceback snipped...]
>
> ProgrammingError at /admin/program/session/15/
> ERROR: invalid input syntax for integer: "" SELECT
> "program_session"."id","program_session"."title","program_session"."short_title","program_session"."description","program_session"."start_id","program_session"."track_id","program_session"."duration"
> FROM "program_session" INNER JOIN "program_timedivision" AS
> "program_session__start" ON "program_session"."start_id" =
> "program_session__start"."id" WHERE ("program_session__start"."id" ILIKE '40'
> AND "program_session"."track_id" = '')
>
> My wild guess here is that this happens because track_id is the primary key
> and thus expects an integer value; had I made the track name its
> primary key it might've worked (?). Anyway, if I want to make that
> change at this point, I don't know how to do so without losing my
> valuable data. Any help you can offer me would be very much
> appreciated.
Can you give a little more information about how you triggered this
error? It looks like you are doing something in the admin, but I am
using null=True foreign keys through the admin successfully without
doing anything special, so it's not totally impossible. It shows up fine
in the admin system and the database stores the reference as a NULL (in
my case). And I'm using PostgreSQL, too, so it's not a db-specific thing
that I can see (although I'm using psycopg1, not psycopg2).
If you triggered the problem just by trying to add a record in the admin
and leaving the "track" reference field empty, it's going to be a little
hard to debug remotely. Try creating a smaller project with a trimmed
down model -- doing the standard "remove stuff until it starts working
or you are only left with the ForeignKey" process.
I can't place what portion of the admin is generating the query you are
seeing, so any information you can provide would be useful.
Regards,
Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
ForeignKey, null, and schema evolution
In my attempt to use
ForeignKey(Track, null=True)
When I actually tried to use a null Track value, I got:
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py" in
get_response
77. response = callback(request, *callback_args, **callback_kwargs)
File
"/usr/lib/python2.4/site-packages/django/contrib/admin/views/decorators.py" in
_checklogin
55. return view_func(request, *args, **kwargs)
File "/usr/lib/python2.4/site-packages/django/views/decorators/cache.py" in
_wrapped_view_func
39. response = view_func(request, *args, **kwargs)
File "/usr/lib/python2.4/site-packages/django/contrib/admin/views/main.py" in
change_stage
325. errors = manipulator.get_validation_errors(new_data)
File "/usr/lib/python2.4/site-packages/django/oldforms/__init__.py" in
get_validation_errors
59. errors.update(field.get_validation_errors(new_data))
File "/usr/lib/python2.4/site-packages/django/oldforms/__init__.py" in
get_validation_errors
357. self.run_validator(new_data, validator)
File "/usr/lib/python2.4/site-packages/django/oldforms/__init__.py" in
run_validator
347. validator(new_data.get(self.field_name, ''), new_data)
File "/usr/lib/python2.4/site-packages/django/db/models/manipulators.py" in
manipulator_validator_unique_together
299. old_obj = self.manager.get(**kwargs)
File "/usr/lib/python2.4/site-packages/django/db/models/manager.py" in get
67. return self.get_query_set().get(*args, **kwargs)
File "/usr/lib/python2.4/site-packages/django/db/models/query.py" in get
211. obj_list = list(clone)
File "/usr/lib/python2.4/site-packages/django/db/models/query.py" in __iter__
103. return iter(self._get_data())
File "/usr/lib/python2.4/site-packages/django/db/models/query.py" in _get_data
430. self._result_cache = list(self.iterator())
File "/usr/lib/python2.4/site-packages/django/db/models/query.py" in iterator
172. cursor.execute("SELECT " + (self._distinct and "DISTINCT " or "") +
",".join(select) + sql, params)
File "/usr/lib/python2.4/site-packages/django/db/backends/util.py" in execute
12. return self.cursor.execute(sql, params)
File "/usr/lib/python2.4/site-packages/django/db/backends/postgresql/base.py"
in execute
43. return self.cursor.execute(sql, [smart_basestring(p, self.charset) for
p in params])
ProgrammingError at /admin/program/session/15/
ERROR: invalid input syntax for integer: "" SELECT
"program_session"."id","program_session"."title","program_session"."short_title","program_session"."description","program_session"."start_id","program_session"."track_id","program_session"."duration"
FROM "program_session" INNER JOIN "program_timedivision" AS
"program_session__start" ON "program_session"."start_id" =
"program_session__start"."id" WHERE ("program_session__start"."id" ILIKE '40'
AND "program_session"."track_id" = '')
My wild guess here is that this happens because track_id is the primary key
and thus expects an integer value; had I made the track name its
primary key it might've worked (?). Anyway, if I want to make that
change at this point, I don't know how to do so without losing my
valuable data. Any help you can offer me would be very much
appreciated.
Thanks,
P.S. I've seen hints elsewhere that you also need blank=True, but that had
no effect for me.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Schema Evolution code
I posted a message on django-developers since I think that is a more common place for discussions to changes in django itself and Russ McGee responded there: http://groups.google.com/group/django-developers/browse_thread/thread/4cbc121bba0c134e Here is the tail end of that response. I suggest following up the discussion there unless I have completely missed the difference between the users and developers list (my impressions synch with Russ's comments so I think I'm right). There is no formal distinction - users are the set of people interested in using Django to develop websites, whereas developers are those interested in contributing to improve Django itself. Anyone is welcome to be a member of either group. Inside the developers, there are the core developers (such as myself) that have commit access to the repository, and branch developers that have commit access to a particular branch of Django. There is a subset of the core developers (Adrian and Jacob) that have administrator access to the repository and can grant commit access to various parts of the tree. Branch developer status will generally be granted to anyone that has a good idea, and can demonstrate that they will be able to deliver what they promise (a prototype implementation is the usual minimum benchmark). Core developer status is the next step, once a reputation for consistent contribution to the community is established. > Any idea what the status is on the potential for a branch, or for > Victor's changes getting rolled into the schema evolution branch? I've > volunteered to put some work into this on the other discussion but am > not sure what the next steps are or who will make those decisions. At the moment, the ball is in Victor's court - he has presented a prototype implementation, so if he wants to champion this cause, he needs to contact Jacob and request SVN access to the schema evolution branch. At that point, he will be the integration person for that branch, so if you want to contribute, he will be the person to coordinate with. If Victor doesn't want the champion role, then the floor is open for someone to step up, with some sample code to prove that they are capable of completing the task. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
If nobody want's to champion the code, I can volunteer ~3-5 hours a week to work on this stuff. My own team needs schema evolution in the long run anyway - so it's well worth my time to make sure this eventually gets back to trunk. I can devote about the same time to it perhaps a bit more in a few weeks. I have done schema migration before although not in python. My company produced a development environment product for mobile computing in 1996 that supported arbitrary schema changes including versioning, and automatic migration from development to test and production systems. Our environment was a bit like Django in that we had a separate model which was semantically richer and allowed us to automatically handle 99% of the database interactions (although in a GUI app). I am not an expert on all the different issues among different databases but I am familiar with many of them at least as they existed a few years back. I have also worked on the internals for SQL database parsers, optimizers, indexing, and have played with the internals of PostgreSQL a bit. I don't know Django very well yet so I'll probably confine myself to testing and bug fixing at first until I come up to speed. - Curtis --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 29-Dec-06, at 9:22 AM, Matthew Flanagan wrote: Victor, have you got a ticket open with your patch? It would be worth opening one so that other people could try it out while you are waiting for commit access to be granted. victor i would suggest you directly mail jacob kaplan-moss with your request for commit access -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Re: Schema Evolution code
On 28/12/06, Steve Hutton <[EMAIL PROTECTED]> wrote: On 2006-12-22, Victor Ng <[EMAIL PROTECTED]> wrote: > > Hi, sorry for the long delay in replying. Holiday season and work > craziness is getting in the way of writing free software - which is > really the fun part isn't it? ;) :-) > It's a little different, but barely. > > The current codebase emits an SQL file with all the SQL statements to > evolve the database, There's no provision to save the version > anywhere, but that would be simple to do. > > If nobody want's to champion the code, I can volunteer ~3-5 hours a > week to work on this stuff. My own team needs schema evolution in the > long run anyway - so it's well worth my time to make sure this > eventually gets back to trunk. > > I won't be able to do too much until the new year though - so that > said - can somebody open up the schema evolution branch, or better - > open up a new branch from trunk so that we can start hacking away at > this problem? Sounds great to me. Any core devs care to open a new branch for this? Thanks, Steve From my earlier involvement I know Victor's code is based on the current schema evolution branch so I think it makes sense for his fixes to be checked into it. Also it would be less confusing for the rest of the django community if there was a single branch, considering that there is atleast one enquiry a week about it. Victor, have you got a ticket open with your patch? It would be worth opening one so that other people could try it out while you are waiting for commit access to be granted. regards matthew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-22, Victor Ng <[EMAIL PROTECTED]> wrote: > > Hi, sorry for the long delay in replying. Holiday season and work > craziness is getting in the way of writing free software - which is > really the fun part isn't it? ;) :-) > It's a little different, but barely. > > The current codebase emits an SQL file with all the SQL statements to > evolve the database, There's no provision to save the version > anywhere, but that would be simple to do. > > If nobody want's to champion the code, I can volunteer ~3-5 hours a > week to work on this stuff. My own team needs schema evolution in the > long run anyway - so it's well worth my time to make sure this > eventually gets back to trunk. > > I won't be able to do too much until the new year though - so that > said - can somebody open up the schema evolution branch, or better - > open up a new branch from trunk so that we can start hacking away at > this problem? Sounds great to me. Any core devs care to open a new branch for this? Thanks, Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 2006-12-24, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > > On 12/24/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote: >> What's the quality of the Schema Evolution code from last summer? > > Not done. > >> Is it >> at all usable? > No. > >> Is it fixable? > Yes. > > Anyway, you seem enthusiastic. > Here's a thread showing recent progress. > http://groups-beta.google.com/group/django-users/browse_thread/thread/bd1417a08e37774a/e157ea7b4a37b556 Well, to be clear, this thread shows that the SOC schema evolution code is *not* being actively maintained or championed for inclusion in the Django trunk. Victor Ng has stepped forward with an alternative implementation, which is good news, but essentially we are back to square one... Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
Thanks, Ned. That seems like a very effective way to do things. It also seems fairly complicated (I have no idea where I would even start with creating an evolution function, or getting the app to check for it on startup). How much work did it take you to set up the infrastructure to do something like that? Would you mind sharing some more about what you did? OT: One of the things I really like about Django (especially compared to Ruby on Rails), is that it's fairly clear in most cases how things work, and (even for a relatively inexperienced programmer like me) where to begin if you need to do something outside the free "generic" stuff. You're always on solid ground. But this is one of the very few things in Django that makes me feel like I'm in over my head. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
This seems a lot like what was supposed to happen in the SoC solution (at least according to what was posted on the Wiki). Derek seemed to do a very good job with the analysis and writing of functional specs, but I think Victor Ng's approach is slightly different. Honestly, I haven't had time to look really closely at either, but I will try to before school starts up again in a week and two days. And then I'll be slammed until June. Todd On Sun, 2006-12-24 at 08:55 -0500, Ned Batchelder wrote: This is the method I've used in a few projects, and am now using with Django in Tabblo: 1) You add a sequentially-increasing number called the schema number to your code. Any time the models change in a way that changes the db schema, this number is incremented. 2) A table is added to the database which records the current schema number in the database. My table has a record for each schema the database has migrated through, rather than just a single record for the current schema, because it provides historic and forensic information, and is going to be tiny anyway. 3) When changing the model, the developer must also write a Python evolution function which applies a delta SQL to update the database schema. This function is named in such a way that the introspection in step 4 can find it automatically. 4) At server startup, the number in the code is compared to the current number in the database. If they are different, evolution functions are found via introspection and executed to update the database. 5) Once the database has been fully evolved, there is a verification step: a test database is created, and populated directly from the models with Django's django.core.management functions. Then the test database and the production database are compared to see if they have the same schema. This method has these advantages: a) Evolution is applied automatically. You can have a development team of any size, each developer with his own dev database, and they will all be upgraded without any attention or coordination by the developer. b) Evolution can involve much more than simple add/drop/alter tables and columns. If you decide to change your FirstName/LastName columns into a single FullName column, the evolution code can do the work to transform the data so that when the evolution is done, all of the data is correct. We've had evolution steps that didn't change the schema at all, merely changed or corrected records in the database. It also has these disadvantages: a) The developer has to write two pieces of code when changing models: the model itself, and the evolution function. In practice, this is somewhat routine, and has not been a burden, and the verifcation in step 5 double-checks that the evolution function and the model change correspond properly. b) It gets very complicated to manage this process when branches are involved, if there will be evolutions on more than one branch at the same time. But I don't know how to simply manage that complexity in any solution. I also wrote a little about it here: http://www.nedbatchelder.com/blog/200512.html#e20051218T105947 --Ned. http://nedbatchelder.com Aaron Jacobs wrote: > > On 12/23/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: >> 2. if you are not worried about data loss run sqlreset - or better, >> drop the database, create it and run syncdb >> 3. if you alter a model, run sqlall, examine the out put to see what >> statements django wants and put them in manually > > These two are fine for a single developer's purposes, but what about > if you want to distribute your app to others? You'd have to come up > with some automated process, even if it's hand-coded. > > I really hope Django gets a migration feature like RoR's sometime soon. > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
This is the method I've used in a few projects, and am now using with Django in Tabblo: 1) You add a sequentially-increasing number called the schema number to your code. Any time the models change in a way that changes the db schema, this number is incremented. 2) A table is added to the database which records the current schema number in the database. My table has a record for each schema the database has migrated through, rather than just a single record for the current schema, because it provides historic and forensic information, and is going to be tiny anyway. 3) When changing the model, the developer must also write a Python evolution function which applies a delta SQL to update the database schema. This function is named in such a way that the introspection in step 4 can find it automatically. 4) At server startup, the number in the code is compared to the current number in the database. If they are different, evolution functions are found via introspection and executed to update the database. 5) Once the database has been fully evolved, there is a verification step: a test database is created, and populated directly from the models with Django's django.core.management functions. Then the test database and the production database are compared to see if they have the same schema. This method has these advantages: a) Evolution is applied automatically. You can have a development team of any size, each developer with his own dev database, and they will all be upgraded without any attention or coordination by the developer. b) Evolution can involve much more than simple add/drop/alter tables and columns. If you decide to change your FirstName/LastName columns into a single FullName column, the evolution code can do the work to transform the data so that when the evolution is done, all of the data is correct. We've had evolution steps that didn't change the schema at all, merely changed or corrected records in the database. It also has these disadvantages: a) The developer has to write two pieces of code when changing models: the model itself, and the evolution function. In practice, this is somewhat routine, and has not been a burden, and the verifcation in step 5 double-checks that the evolution function and the model change correspond properly. b) It gets very complicated to manage this process when branches are involved, if there will be evolutions on more than one branch at the same time. But I don't know how to simply manage that complexity in any solution. I also wrote a little about it here: http://www.nedbatchelder.com/blog/200512.html#e20051218T105947 --Ned. http://nedbatchelder.com Aaron Jacobs wrote: On 12/23/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: 2. if you are not worried about data loss run sqlreset - or better, drop the database, create it and run syncdb 3. if you alter a model, run sqlall, examine the out put to see what statements django wants and put them in manually These two are fine for a single developer's purposes, but what about if you want to distribute your app to others? You'd have to come up with some automated process, even if it's hand-coded. I really hope Django gets a migration feature like RoR's sometime soon. > -- Ned Batchelder, http://nedbatchelder.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 12/24/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote: What's the quality of the Schema Evolution code from last summer? Not done. Is it at all usable? No. Is it fixable? Yes. Is anyone else worried that Google won't be so keen to give Django coders they've spent thousands of dollars on if their investment doesn't even make a difference in the project because the code never ends up in there? No. I see lots of SoC projects stagnate, but lots more make it. I think SoC is a bit like YCombinator in the sense that they're scattering peanuts to see what grows. And it's good PR as well as a recruiting tool. Anyway, you seem enthusiastic. Here's a thread showing recent progress. http://groups-beta.google.com/group/django-users/browse_thread/thread/bd1417a08e37774a/e157ea7b4a37b556 Brother, can you lend a hand? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On Sun, 2006-12-24 at 11:38 +0530, Kenneth Gonsalves wrote: On 24-Dec-06, at 8:50 AM, ringemup wrote: > Yeah, I'm good with syncdb when adding a model, it's when I > add/remove/change a field that problems occur. > > Sqlreset sounds convenient... how do you deal, though, with > re-inputting data for testing once you modify a model? ready made scripts - run outside django What's the quality of the Schema Evolution code from last summer? Is it at all usable? Is it fixable? Is anyone else worried that Google won't be so keen to give Django coders they've spent thousands of dollars on if their investment doesn't even make a difference in the project because the code never ends up in there? Todd --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 24-Dec-06, at 9:01 AM, Aaron Jacobs wrote: 2. if you are not worried about data loss run sqlreset - or better, drop the database, create it and run syncdb 3. if you alter a model, run sqlall, examine the out put to see what statements django wants and put them in manually These two are fine for a single developer's purposes, but what about if you want to distribute your app to others? You'd have to come up with some automated process, even if it's hand-coded. each time you change your schema, you write the appropriate sql script and give it to your users. This is what the django devels do when they make backward incompatible changes. -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 24-Dec-06, at 8:50 AM, ringemup wrote: Yeah, I'm good with syncdb when adding a model, it's when I add/remove/change a field that problems occur. Sqlreset sounds convenient... how do you deal, though, with re-inputting data for testing once you modify a model? ready made scripts - run outside django -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 12/23/06, ringemup <[EMAIL PROTECTED]> wrote: Yeah, I'm good with syncdb when adding a model, it's when I add/remove/change a field that problems occur. Sqlreset sounds convenient... how do you deal, though, with re-inputting data for testing once you modify a model? This is becoming a FAQ. :) See the email I sent (with attachment) in this thread: http://groups-beta.google.com/group/django-users/browse_thread/thread/bd1417a08e37774a/e157ea7b4a37b556 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 12/23/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: 2. if you are not worried about data loss run sqlreset - or better, drop the database, create it and run syncdb 3. if you alter a model, run sqlall, examine the out put to see what statements django wants and put them in manually These two are fine for a single developer's purposes, but what about if you want to distribute your app to others? You'd have to come up with some automated process, even if it's hand-coded. I really hope Django gets a migration feature like RoR's sometime soon. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
Yeah, I'm good with syncdb when adding a model, it's when I add/remove/change a field that problems occur. Sqlreset sounds convenient... how do you deal, though, with re-inputting data for testing once you modify a model? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Your Approach to Schema Evolution?
On 21-Dec-06, at 2:14 AM, ringemup wrote: In the meantime, I'm interested in picking up some ideas: how do you deal with changing database structures as you develop a Django app? 1. if you just add a new model - run syncdb and it automatically gets added 2. if you are not worried about data loss run sqlreset - or better, drop the database, create it and run syncdb 3. if you alter a model, run sqlall, examine the out put to see what statements django wants and put them in manually -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Your Approach to Schema Evolution?
Hello all -- I'm aware that there are long-term plans to provide for schema evolution in Django (much like RoR's "Migrations". In the meantime, I'm interested in picking up some ideas: how do you deal with changing database structures as you develop a Django app? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
Hi, sorry for the long delay in replying. Holiday season and work craziness is getting in the way of writing free software - which is really the fun part isn't it? ;) On 12/17/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > Ways in which my schema evolution code sucks: > 1) converting the database is done pretty much all automatically so > you don't really have a way to version control your schema changes > Is this a departure from the Proposal in the wiki[1]? It says: "Introspection + migration This approach is a combination of Automatic db introspection and Automatically applied migration code -- one command produces a migration script, you tickle your version number, and the syncdb runs the migrations" It's a little different, but barely. The current codebase emits an SQL file with all the SQL statements to evolve the database, There's no provision to save the version anywhere, but that would be simple to do. If nobody want's to champion the code, I can volunteer ~3-5 hours a week to work on this stuff. My own team needs schema evolution in the long run anyway - so it's well worth my time to make sure this eventually gets back to trunk. I won't be able to do too much until the new year though - so that said - can somebody open up the schema evolution branch, or better - open up a new branch from trunk so that we can start hacking away at this problem? victor "i hate parking lots at christmas" ng -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-11, Victor Ng <[EMAIL PROTECTED]> wrote: > > I've got a rough version of schema evolution working now. > > The basic implementation is what the SoC project was trying to do. [...] > I honestly think it's a *bad* solution to the problem. I've been > looking at sqlalchemy and the 'migrate' project : > > http://erosson.com/migrate/trac/ > > and it seems like it's a better solution for a couple reasons. > > Ways in which my schema evolution code sucks: > > 1) converting the database is done pretty much all automatically so > you don't really have a way to version control your schema changes Is this a departure from the Proposal in the wiki[1]? It says: "Introspection + migration This approach is a combination of Automatic db introspection and Automatically applied migration code -- one command produces a migration script, you tickle your version number, and the syncdb runs the migrations" Steve [1] http://code.djangoproject.com/wiki/SchemaEvolution --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-17, Victor Ng <[EMAIL PROTECTED]> wrote: > > Test coverage is ~44 test cases. There are currently 2 known problems > in the code from a 'correctness' standpoint, and there is a ton of > refactoring that needs to be done before it should be considered for > merging into the trunk. I see, 44 test cases sound like a good start. > The code is *messy*. Writing schema evolution went hand in hand with > me learning how Django's schema generation worked. [...] > If someone wants to open up commit access on the django branch for > schema evo, I'll be happy to bring the schema evo code up to date with > the trunk. > > I *do* need help in tidying it up to get it merged back to trunk > though. I'm hard pressed for time right now and I could use some > help. It sounds like your code has potential to be a full fledged alternative implementation. I've never looked at the django internals, but I might be able to help nevertheless. I will have some time starting about 10 days from now. At this point it would be a question of where I spend my time - testing the existing branch code or helping test and/or clean up and integrate your code. The fact that you've already tried the existing schema evolution branch and spent this much effort so far on an alternative implementation certainly makes me lean towards your code. But it would be nice from a logistical point of view if we could have access it to it from a repository somewhere. Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-15, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Either way, the ultimate goal would be to convince Adrian that the > branch is stable, get him to take a look at it, and merge the branch > into the trunk. Adrian is pretty busy, so I'm guessing he would be > looking for some community consensus that the branch is complete and > stable before he spends any time looking at it. Absolutely makes sense to me. >> Maybe someone is already thinking along these lines? It seems like the >> branch could benefit from a "champion" who actively pushes it through. > > This 'champion' role should be performed by Derek and/or Kenneth > Gonsalves (the SOC mentor for the project). Right, also makes sense. It would be nice to get Derek and Kenneth's thoughts on the status of the branch and what they think the remaining tasks are to make it "merge ready". > If you want to help out, > check out the branch, and take it for a test drive. If what you find > is stable, let the community know; if it isn't, log bugs (and patches > if you can) until it is. Thanks, I plan on doing just that in the coming weeks. However I'm not sure yet if I'll be trying Victor's alternative implementation or the existing branch. Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-17, Victor Ng <[EMAIL PROTECTED]> wrote: > > FYI - the schema evolution code submitted from the SoC project doesn't > work, so keeping it up to date is a moot point. There have been > several posts from people trying to use it where the SoC version of > the schema evolution code just halts. > > The implementation in my patch is basically a complete rewrite. The > only things I've kept are the 'aka' attribute definitions in the Field > and the Model.Meta classes. Ah, I see. Your comments and the fact that the schema evolution branch has not been actively updated lately or championed make me disinclined to spend time testing it. Perhaps your patches could form the basis of an alternative schema evolution branch? Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
FYI - the schema evolution code submitted from the SoC project doesn't work, so keeping it up to date is a moot point. There have been several posts from people trying to use it where the SoC version of the schema evolution code just halts. The implementation in my patch is basically a complete rewrite. The only things I've kept are the 'aka' attribute definitions in the Field and the Model.Meta classes. vic On 12/15/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > > > There was discussion about the general problem of schema evolution > > before the SOC project was started. The discussion was started by > > Jacob, and other committers (Luke and Malcolm) weighed in at the time, > > along with many other interested onlookers. The resulting design is on > > the wiki. > > That's good to hear. > > > Assuming that the implementation matches the proposal, I would say > > there is a realistic chance of it getting accepted into core. However, > > this would require that the implementation is up to date, and bug free > > (including tests to validate this status that are integrated into the > > Django system tests). > The tests I've added to the schema evolution code are fully automated, but they aren't currently integrated into the main Django test suite. The main reason for this is that the schema evolution code relies on a Postgresql backend. You can't run the tests against MySQL or SQLite. MySQL doesn't work because I haven't looked at it yet, and SQLite is probably going to be impossible to implement since sqlite doesn't implement a proper ALTER TABLE statement. > I see. It sounds like it may be a bit of moving target, due to changes > in core. Maybe a good goal would be to get the implementation up to > date (maybe that's what Victor has done?) and make sure the test > coverage is in place (I'm not sure the status of this?). Test coverage is ~44 test cases. There are currently 2 known problems in the code from a 'correctness' standpoint, and there is a ton of refactoring that needs to be done before it should be considered for merging into the trunk. The code is *messy*. Writing schema evolution went hand in hand with me learning how Django's schema generation worked. That said - the modifications are basically: * decomposing a lot of functions in django.core.managemeent so that they're more re-usabl * removing all REFERENCES clauses in CREATE TABLE statements and changed the code to just emit CREATE CONSTRAINT statements. This makes everything more consistent and easier for me to figure out what constraints to remove later if the schema is changed. * rewriting the syncdb function since it missed creating some foreign key relationships sometimes * most of the heavy lifting is in django.contrib.schemaevo - again, it's all Postgresql specific and I just ripped out the code that I wrote into django.core.management and dropped it into django.contrib.schemaevo. Minor changes were made to get my tests to run again. > Maybe someone is already thinking along these lines? It seems like the > branch could benefit from a "champion" who actively pushes it through. If someone wants to open up commit access on the django branch for schema evo, I'll be happy to bring the schema evo code up to date with the trunk. I *do* need help in tidying it up to get it merged back to trunk though. I'm hard pressed for time right now and I could use some help. vic -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Switching branches (was "Schema Evolution code")
On 12/15/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > On 12/15/06, Waylan Limberg <[EMAIL PROTECTED]> wrote: > > No mention of the cross-platform path files? I would say they are > > easier to edit (comment/uncomment a line in a file) than symlink and > > as they are a python feature (not an OS feature) they work on any OS. > > Hey Waylan, > > A patch to the documentation would be welcome. :) > Done: http://code.djangoproject.com/ticket/3147 I hope it is clear enough. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Switching branches (was "Schema Evolution code")
On 12/15/06, Waylan Limberg <[EMAIL PROTECTED]> wrote: > No mention of the cross-platform path files? I would say they are > easier to edit (comment/uncomment a line in a file) than symlink and > as they are a python feature (not an OS feature) they work on any OS. Hey Waylan, A patch to the documentation would be welcome. :) Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Switching branches (was "Schema Evolution code")
On 12/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > I've added some more instructions to the "Using branches" part of our > documentation. Let me know if this helps. > > http://www.djangoproject.com/documentation/contributing/#using-branches > > Adrian > No mention of the cross-platform path files? I would say they are easier to edit (comment/uncomment a line in a file) than symlink and as they are a python feature (not an OS feature) they work on any OS. Just place the file `django.pth` in your site-packages dir (or anywhere on your pythonpath). The file would look something like this: /path/to/django_src # /path/to/django_branch1 # /path/to/django_branch2 If you want to switch to branch2, just edit the file and comment line one and uncomment line 3. It's that easy. For more on path files see this page: http://bob.pythonmac.org/archives/2005/02/06/using-pth-files-for-python-development/ -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Re: Schema Evolution code
On 12/15/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > > > Assuming that the implementation matches the proposal, I would say > > there is a realistic chance of it getting accepted into core. However, > > this would require that the implementation is up to date, and bug free > > (including tests to validate this status that are integrated into the > > Django system tests). > > I see. It sounds like it may be a bit of moving target, due to changes > in core. Maybe a good goal would be to get the implementation up to > date (maybe that's what Victor has done?) and make sure the test > coverage is in place (I'm not sure the status of this?). Keeping everything up to date is the role of the champion you mention below. > Then publicize it a bit and call for testers to essentially try what > would essentially be a release candidate. The call for testing should be made by the champion; unless I've missed a post, I don't think this has happened. The branch hasn't been touched for 2 months, but I don't know if this is because the work is done, or because Derek Anderson (the SOC participant running the schema-evolution project) hasn't had time to work on it, or if he has just lost interest. Either way, the ultimate goal would be to convince Adrian that the branch is stable, get him to take a look at it, and merge the branch into the trunk. Adrian is pretty busy, so I'm guessing he would be looking for some community consensus that the branch is complete and stable before he spends any time looking at it. > Maybe someone is already thinking along these lines? It seems like the > branch could benefit from a "champion" who actively pushes it through. This 'champion' role should be performed by Derek and/or Kenneth Gonsalves (the SOC mentor for the project). If you want to help out, check out the branch, and take it for a test drive. If what you find is stable, let the community know; if it isn't, log bugs (and patches if you can) until it is. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-14, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 12/13/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > >> Does it have a realistic chance of being accepted into core if it's found >> to be bug free? Is it fully documented? Is the design controversial or >> does it follow a community consensus? > > There was discussion about the general problem of schema evolution > before the SOC project was started. The discussion was started by > Jacob, and other committers (Luke and Malcolm) weighed in at the time, > along with many other interested onlookers. The resulting design is on > the wiki. That's good to hear. > Assuming that the implementation matches the proposal, I would say > there is a realistic chance of it getting accepted into core. However, > this would require that the implementation is up to date, and bug free > (including tests to validate this status that are integrated into the > Django system tests). I see. It sounds like it may be a bit of moving target, due to changes in core. Maybe a good goal would be to get the implementation up to date (maybe that's what Victor has done?) and make sure the test coverage is in place (I'm not sure the status of this?). Then publicize it a bit and call for testers to essentially try what would essentially be a release candidate. Maybe someone is already thinking along these lines? It seems like the branch could benefit from a "champion" who actively pushes it through. Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-14, Victor Ng <[EMAIL PROTECTED]> wrote: > > The patch I previous sent in mostly adds a couple functions to the > psycopg2 backend in the introspection module. The only big changes > that affect the mainline django code are in django.core.management. > > I'm using my patches, so that's been tested through 3 schema updates > in production. As previously mentioned -there are those 2 remaining > bugs in the schema-evo code, but they're not show stoppers for me. > > I see no reason why people need to use the latest trunk to test beta > quality features. That just makes no sense - if you need beta > features - use a branch, or apply my patch to your own copy of trunk. > Is there a problem that I'm not seeing? I'm quite sure that all the > code that my patch modifies hasn't been touched in over a month, so it > should apply cleanly to trunk. Victor, thanks very much for your efforts on this. I will be starting a new project soon and would like to test schema evolution. Can you explain the differences between your patch and the schema evolution branch itself? Are you proposing that your changes be rolled be rolled into the schema evolution branch? Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Switching branches (was "Schema Evolution code")
>> Are there any "best practices" tips for swapping among them for >> testing/experimenting? Preferably without causing /too/ much >> damage. :) > > Hey Tim, > > I've added some more instructions to the "Using branches" part of our > documentation. Let me know if this helps. > > http://www.djangoproject.com/documentation/contributing/#using-branches Yes, thanks! I think with a combo of symlinks and the other response regarding a personalized environment, I think my final solution will be to 1) adjust my $PYTHONPATH to point to a ~/projects/django symlink 2) redirect that symlink to point to various branches of interest My kudos to the Django team...a while back I had started my own framework (what Python programmer hasn't? ;) with a number of goals in mind. However, as I learned about Django, I found that it already had implemented nearly all of what I wanted. There are still the two aforementioned issues that are solved in branches (row-level permissions and schema evolution), but it looks like those will come down the pike and eventually merge with the trunk. Thanks! -tkc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Re: Schema Evolution code
The patch I previous sent in mostly adds a couple functions to the psycopg2 backend in the introspection module. The only big changes that affect the mainline django code are in django.core.management. I'm using my patches, so that's been tested through 3 schema updates in production. As previously mentioned -there are those 2 remaining bugs in the schema-evo code, but they're not show stoppers for me. I see no reason why people need to use the latest trunk to test beta quality features. That just makes no sense - if you need beta features - use a branch, or apply my patch to your own copy of trunk. Is there a problem that I'm not seeing? I'm quite sure that all the code that my patch modifies hasn't been touched in over a month, so it should apply cleanly to trunk. vic On 12/14/06, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > > I know the company line on the SOC Schema Evolution code is that it will > be integrated into the trunk after enough people have tested it, but I > think this creates a chicken and egg problem. People aren't going to use > it until it's in trunk and it won't be in trunk until enough people test > it. > > Does it impact normal use without using schema evolution? In other > words, could it be integrated into trunk with the proviso that > > "The Schema Evolution feature should be considered beta. If you use this > feature, please test the results carefully and report any bugs you find. > If you don't use Schema Evolution, you shouldn't be affected." > > I'd really like to try it, but I don't have time to keep up to date with > two branches. > > Todd > > On Thu, 2006-12-14 at 21:22 +0800, Russell Keith-Magee wrote: > > On 12/13/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > > > > > Does it have a realistic chance of being accepted into core if it's found > > > to be bug free? Is it fully documented? Is the design controversial or > > > does it follow a community consensus? > > > > There was discussion about the general problem of schema evolution > > before the SOC project was started. The discussion was started by > > Jacob, and other committers (Luke and Malcolm) weighed in at the time, > > along with many other interested onlookers. The resulting design is on > > the wiki. > > > > Assuming that the implementation matches the proposal, I would say > > there is a realistic chance of it getting accepted into core. However, > > this would require that the implementation is up to date, and bug free > > (including tests to validate this status that are integrated into the > > Django system tests). > > > > Yours, > > Russ Magee %-) > > > > > > > > > > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Switching branches (was "Schema Evolution code")
On 12/14/06, Tim Chase <[EMAIL PROTECTED]> wrote: > Now I'd like to toy with both the Schema Evolution and the > row-level user privs branches. > > Are there any "best practices" tips for swapping among them for > testing/experimenting? Preferably without causing /too/ much > damage. :) Hey Tim, I've added some more instructions to the "Using branches" part of our documentation. Let me know if this helps. http://www.djangoproject.com/documentation/contributing/#using-branches Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Re: Switching branches (was "Schema Evolution code")
On 12/14/06, Tim Chase <[EMAIL PROTECTED]> wrote: > Are there any "best practices" tips for swapping among them for > testing/experimenting? Preferably without causing /too/ much > damage. :) I can only speak to Unix-based systems, but what I've done with lots of things of this nature is write a little script which will rewrite the .profile and .rc files for my shell to have various environment variables (in this case, PYTHONPATH) point to different locations, then use 'source' to force the files to reload. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Switching branches (was "Schema Evolution code")
> If you don't use Schema Evolution, you shouldn't be affected." > > I'd really like to try it, but I don't have time to keep up to date with > two branches. Early on, I naively just did the generic install of Django which put it in the usual system-wide place. Now I'd like to toy with both the Schema Evolution and the row-level user privs branches. Are there any "best practices" tips for swapping among them for testing/experimenting? Preferably without causing /too/ much damage. :) Thanks, -tkc --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Re: Schema Evolution code
I know the company line on the SOC Schema Evolution code is that it will be integrated into the trunk after enough people have tested it, but I think this creates a chicken and egg problem. People aren't going to use it until it's in trunk and it won't be in trunk until enough people test it. Does it impact normal use without using schema evolution? In other words, could it be integrated into trunk with the proviso that "The Schema Evolution feature should be considered beta. If you use this feature, please test the results carefully and report any bugs you find. If you don't use Schema Evolution, you shouldn't be affected." I'd really like to try it, but I don't have time to keep up to date with two branches. Todd On Thu, 2006-12-14 at 21:22 +0800, Russell Keith-Magee wrote: > On 12/13/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > > > Does it have a realistic chance of being accepted into core if it's found > > to be bug free? Is it fully documented? Is the design controversial or > > does it follow a community consensus? > > There was discussion about the general problem of schema evolution > before the SOC project was started. The discussion was started by > Jacob, and other committers (Luke and Malcolm) weighed in at the time, > along with many other interested onlookers. The resulting design is on > the wiki. > > Assuming that the implementation matches the proposal, I would say > there is a realistic chance of it getting accepted into core. However, > this would require that the implementation is up to date, and bug free > (including tests to validate this status that are integrated into the > Django system tests). > > Yours, > Russ Magee %-) > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Re: Schema Evolution code
If anyone wants to poke at our schema evolution code you should be able to apply this patch attached. It's mostly working. The bugs I know about are: 1) M2M fields can't be repointed at new tables properly 2) there's some weird quirk with modifying null and db_index at the same time. i have to run the sqlevolve command twice to get the column to get altered and to have the index added. The patch also fixes a couple problems I discovered in Django's existing syncdb command and the way it handles unique and db_index arguments. Those bugs were: 1) syncdb sometimes seems to 'miss' setting up foreign key constraints between applications. 2) foreign key constraints were specified inconsistently. Sometimes a 'REFERENCES' clause was added to the CREATE TABLE and sometimes a CREATE CONSTRAINT was used. This caused problems with figuring out the names of the constraints I needed to remove. 3) indexes were created multiple times sometimes in cases where a primary key was set. 4) indexes were *not* created for unique columns. technically not a bug, but i can't see why you wouldn't want an index. For small tables, the cost of the inserting a record against an index is small - it's a small table and there just aren't that many inserts. For large tables, the lack of an index means you're going to incur a table scan. Again - this code is ugly and needs to be cleaned up a lot, but it's working well enough for us against postgresql+psycopg2. It doesn't work on any other backend. Test cases are in the tests/evolvedb/runtests.py script. You'll need to symlink from tests/evolvedbtests/db_settings/settings.py.postgresql script to tests/evolvedbtests/backend_settings.py. All the existing django tests seem to pass with my patches applied. There's no documentation but there's ~40 odd tests checked into that evolvedb tests directory. Unfortunately, I'm pressed for time for the forseeable future and I don't think I'll be able to spend a lot more time working on this code. vic On 12/14/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 12/13/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > > > Does it have a realistic chance of being accepted into core if it's found > > to be bug free? Is it fully documented? Is the design controversial or > > does it follow a community consensus? > > There was discussion about the general problem of schema evolution > before the SOC project was started. The discussion was started by > Jacob, and other committers (Luke and Malcolm) weighed in at the time, > along with many other interested onlookers. The resulting design is on > the wiki. > > Assuming that the implementation matches the proposal, I would say > there is a realistic chance of it getting accepted into core. However, > this would require that the implementation is up to date, and bug free > (including tests to validate this status that are integrated into the > Django system tests). > > Yours, > Russ Magee %-) > > > > -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~--- schema_evo.patch.gz Description: GNU Zip compressed data
Re: Re: Schema Evolution code
On 12/13/06, Steve Hutton <[EMAIL PROTECTED]> wrote: > Does it have a realistic chance of being accepted into core if it's found > to be bug free? Is it fully documented? Is the design controversial or > does it follow a community consensus? There was discussion about the general problem of schema evolution before the SOC project was started. The discussion was started by Jacob, and other committers (Luke and Malcolm) weighed in at the time, along with many other interested onlookers. The resulting design is on the wiki. Assuming that the implementation matches the proposal, I would say there is a realistic chance of it getting accepted into core. However, this would require that the implementation is up to date, and bug free (including tests to validate this status that are integrated into the Django system tests). Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 2006-12-11, Victor Ng <[EMAIL PROTECTED]> wrote: > Hi Russ, > > I've got a rough version of schema evolution working now. > > The basic implementation is what the SoC project was trying to do. [...] > On 12/3/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: [...] >> The behaviour you are seeking is under development in the schema >> evolution >> branch. I don't know the status of this branch for certain; it was >> the >> subject of a Google 'summer of code' project, and I believe that the >> engineering work is complete, but requires feedback and review before >> it is >> committed to the trunk (I could be wrong on this - anybody in the >> loop on >> this stream care to comment?) >> >> Anyway - the wiki describes what was intended for this stream: >> >> http://code.djangoproject.com/wiki/SchemaEvolution I get the impression that there's not a lot of momentum behind the schema evolution branch at the moment. It seems it hasn't been brought up to date with head in a while. My status query on the developer list didn't result in any replies. I'm kind of surprised at this, since I think its a pretty frequently requested feature. Does anyone here who has tried the schema evolution branch care to comment? Does it have a realistic chance of being accepted into core if it's found to be bug free? Is it fully documented? Is the design controversial or does it follow a community consensus? Thanks, Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution code
On 12/10/06, Victor Ng <[EMAIL PROTECTED]> wrote:
>
> Hi Russ,
>
> I've got a rough version of schema evolution working now.
...
> I honestly think it's a *bad* solution to the problem. I've been
> looking at sqlalchemy and the 'migrate' project :
The attached file is in no way a complete solution, but it's working
for us with PegasusNews.com. It doesn't handle rollback; we assume a
db restore of an old version is the likely recovery approach. :)
We're using postgresql and an old version of django, but with
adjustments, the script should be workable for lots of people. One
thing to note is that postgresql can do almost any schema changes
under a single transaction. This is an unusual feature, and the
script would be much more complicated for, say, mssql or oracle. It
gives nice error messages and generally tries hard to only fail in
clean ways.
db_upgrade.py is a general driver script. It expects a setting,
UPGRADE_STEPS_PATH, to define the path at which a separate
upgrade_steps module can be imported. See the attached
upgrade_steps.py for further usage notes. db_upgrade.py also expects
the target schema to have a table named db_version which defines the
current version.
texasgigs=> \d db_version
Table "public.db_version"
Column | Type | Modifiers
-+---+---
branch | character varying(50) |
version | integer |
The general approach is to get the version from the db, the highest
version magically-named migration function in the upgrade_steps
module, backup the existing db, and then successively run the
migration functions until either all of them have been run or an error
occurs.
If DEBUG=True, commits are done between each migration function.
Also, note that the passed conn and cursor are Django's wrapped
conn/cursor, so you are free to use the DJ DB API in the migrations;
you aren't limited to SQL via conn/cursor.
I hope it's useful to someone, and let me know of any questions.
-Jeremy
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
"""
This script is called by ./util/db_upgrade.py.
Functions in here are passed an open connection and related cursor.
Functions should be named ,
e.g. trunk2 takes trunk from version 1 to version 2 of the database.
Make a new function for each commit (unless you're fixing a data-eating upgrade FUBAR).
If you're making schema changes, mention the new DB version number in svn commit messages.
Throw errors from here if bad things happen in the upgrade; they'll be handled in the driver script.
Don't update db_version or commit in here; the driver script will take care of it.
"""
def trunk2(conn, cursor):
cursor.execute("some sql statements here")
def trunk3(conn, cursor):
cursor.execute("""
UPDATE categories set representation = replace(representation, '/', '>');
""")
from django.conf.settings import UPGRADE_STEPS_PATH
from ellington.categories.parts import import_categories
import os
fn = os.path.join(UPGRADE_STEPS_PATH,"dy", "cats")
import_categories.import_categories(fn)
#!/usr/bin/python
import sys, os
import psycopg
from django.core.db import db
from django.conf.settings import DATABASE_USER, DATABASE_NAME, DATABASE_HOST, DATABASE_PORT, DATABASE_PASSWORD, DEBUG, TIME_ZONE, UPGRADE_STEPS_PATH, DEBUG
def usage():
sys.stderr.write("%s [--nobackup] \n Expects DJANGO_SETTINGS_MODULE to be set.\n")
if len(sys.argv) == 1:
do_backup = True
else:
if sys.argv[1] == "--nobackup":
do_backup = False
else:
usage()
sys.exit()
try:
os.environ['DJANGO_SETTINGS_MODULE']
except KeyError:
usage()
sys.exit()
def get_conn_string():
if DATABASE_NAME == '':
from django.core.exceptions import ImproperlyConfigured
raise ImproperlyConfigured, "You need to specify DATABASE_NAME in your Django settings file."
conn_string = "dbname=%s" % DATABASE_NAME
if DATABASE_USER:
conn_string = "user=%s %s" % (DATABASE_USER, conn_string)
if DATABASE_PASSWORD:
conn_string += " password='%s'" % DATABASE_PASSWORD
if DATABASE_HOST:
conn_string += " host=%s" % DATABASE_HOST
if DATABASE_PORT:
conn_string += " port=%s" % DATABASE_PORT
Re: Django Quick Start with Schema Evolution Support
Ilias Lazaridis wrote: > http://lazaridis.com/core/eval/index.html Your phone contact is not working. I get the impression you're only a scam. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
> Again, can we just let this thread die? Per the Wikipedia entry on > him, Ilias has been banned from posting to this list. This does not feel right. Though I understand the reasons that may have led the admins to this decision, it's always a failure when a community cannot evolve a way to handle a dysfunctional situation, and has to be prevented to face it, for whatever good reasons. Freedom of speech should be preserved in all but the direst occurrences, in which there is direct and evident harm to others. This did not seem such a case. -- Nicola Larosa - http://www.tekNico.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
On 6/5/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > I didn't know Wikipedia administered this list? Sure, the entry does > point out he has had a few problems on the mailinglists, a lot owing > up to his own behaviour. However, see below. The Wikipedia article is not the authoritative source, true. However, I updated it after hearing from authoritative sources that he has been banned. > The file points to LICENSE.TXT in the directory evolve.py is in. This > LICENSE.TXT is a BSD 3-clause license just like Lawrence Journal used, > just attributed to himself and stamped 2006. Nothing weird there. I'd still want to run it by an IP lawyer. > I am all for letting a thread die, just for the right reasons though > and that's currently *not* happening as far as I can see. OK. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
On 6/5/06, James Bennett <[EMAIL PROTECTED]> wrote: > Again, can we just let this thread die? Per the Wikipedia entry on > him, Ilias has been banned from posting to this list. I didn't know Wikipedia administered this list? Sure, the entry does point out he has had a few problems on the mailinglists, a lot owing up to his own behaviour. However, see below. > As for code that he wrote, I'd personally be wary of us ever using > anything he didn't post to our own Trac and, even then, I'd probably > want to run it by an IP lawyer before doing anything with it -- code > contributed by a supposed "analyst for hire" who seemed to be fishing > for us to pay him to help with Django is likely to be of questionable > legal status. The file points to LICENSE.TXT in the directory evolve.py is in. This LICENSE.TXT is a BSD 3-clause license just like Lawrence Journal used, just attributed to himself and stamped 2006. Nothing weird there. I am all for letting a thread die, just for the right reasons though and that's currently *not* happening as far as I can see. The Internet's group mentality can also be very quick in getting out the tar and feathers and label someone unwanted. And this will be the last notice from my side on this, unless it has to do with the technical side of things. -- Jeroen Ruigrok van der Werven --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
On 6/5/06, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > Ilias, could you stop replying to every single email and just ignore > ad hominems? Thanks. > And to the rest, could you please focus on purely the technical > content instead of polluting the list with unnecessary replies? Again, can we just let this thread die? Per the Wikipedia entry on him, Ilias has been banned from posting to this list. As for code that he wrote, I'd personally be wary of us ever using anything he didn't post to our own Trac and, even then, I'd probably want to run it by an IP lawyer before doing anything with it -- code contributed by a supposed "analyst for hire" who seemed to be fishing for us to pay him to help with Django is likely to be of questionable legal status. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Allow me to cut through the crap from both sides. Ilias, could you stop replying to every single email and just ignore ad hominems? Thanks. And to the rest, could you please focus on purely the technical content instead of polluting the list with unnecessary replies? Thanks. On 6/5/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution > http://case.lazaridis.com/multi/browser/django/rework/evolve.py > http://case.lazaridis.com/multi/browser/django/rework/add_evolvedb_command.diff Has anybody even looked at the above? A cursory glance of evolve.py shows that some preliminary work has been done on the schema evolution. How much of that of the above is useful/workable? I readily admit this is not quite my cup of tea. -- Jeroen Ruigrok van der Werven --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
yep. i feel particularly hosed for trying to work with you offline to synchronize our efforts. and even more retarded for the time i spent and help i offered regarding your web site design, resume and general "how to better present yourself" as a consulting business. (considering i've been a fulltime programmer/consultant for many years now and you were claiming to just be starting out) however i am far from your largest detractor here. and i don't wish to be, so i won't contribute any more to this discussion. this will be my last post here regarding you. -- derek p.s. for the record i'm not totally convinced you're an intentional troll. i suspect you're just socially and professionally inept. but with your history on other listservs, it seems that you are incapable of learning how to better interact with others. so "a rose by any other name..." the effect is the same. i recommend to all ignoring ilias here. > Derek Anderson wrote: >> i believe it's time for... > > Mr. Anderson, > > we had some private conversation at the start of my work with Django, > where I had answered all of your questions. > > Based on this, you should have a better rating about me, especially when > knowing my private situation (or at least some indicators). > > - > > You are the Student which will execute the "Google Summer of Code" > Project, which will implement the "Schema Evolution Support for Django", > > http://code.djangoproject.com/wiki/SchemaEvolution > > May I ask you to point my to a resource which shows your current plans, > results etc.? > > As you have seen, I have provided within a few days something what the > django project and its community has not provided since a _very_ long > time. > > A working draft version of a Schema Evolution Support for Django: > > http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution > > - > > You should understand that it looks really somehow, that especially you > talk so loud about a 'troll'. > > Finally, you should be aware of something: all of your writings were > publically archived. > >> ___ >>/| /| | | >>||__|| | Please don't | >> / O O\__ feed | >> / \ the trolls| >> / \ \| >>/ _\ \ -- >> /|\\ \ || >> / | | | |\/ || >> / \|_|_|/ |__|| >>/ / \|| || >> / | | /|| --| >> | | |// | --| >>* _| |_|_|_| | \-/ >> *-- _--\ _ \ // | >> / _ \\ _ // |/ >> * / \_ /- | - | | >> * ___ c_c_c_C/ \C_c_c_c >> >> -- derek :) > > . > > -- > http://lazaridis.com > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Derek Anderson wrote: > i believe it's time for... Mr. Anderson, we had some private conversation at the start of my work with Django, where I had answered all of your questions. Based on this, you should have a better rating about me, especially when knowing my private situation (or at least some indicators). - You are the Student which will execute the "Google Summer of Code" Project, which will implement the "Schema Evolution Support for Django", http://code.djangoproject.com/wiki/SchemaEvolution May I ask you to point my to a resource which shows your current plans, results etc.? As you have seen, I have provided within a few days something what the django project and its community has not provided since a _very_ long time. A working draft version of a Schema Evolution Support for Django: http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution - You should understand that it looks really somehow, that especially you talk so loud about a 'troll'. Finally, you should be aware of something: all of your writings were publically archived. > ___ >/| /| | | >||__|| | Please don't | > / O O\__ feed | > / \ the trolls| > / \ \| >/ _\ \ -- > /|\\ \ || > / | | | |\/ || > / \|_|_|/ |__|| >/ / \|| || > / | | /|| --| > | | |// | --| >* _| |_|_|_| | \-/ > *-- _--\ _ \ // | > / _ \\ _ // |/ > * / \_ /- | - | | > * ___ c_c_c_C/ \C_c_c_c > > -- derek :) . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Guys, I don't know who this guy is, or why everyone hates him (and I don't want to know, so don't take this as an invitation to tell me). But it seems to me that if he is a troll then you all have played into his hands by posting a bunch of off topic slurs against him, resulting in our mailboxes being full of garbage. It's not just him - it is you, too. Perpetual posts about him being a troll are just as bothersome to the rest of us as posts from an actual troll. So just cut it out. If you don't like him or his question, just don't answer. Please! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
i believe it's time for... ___ /| /| | | ||__|| | Please don't | / O O\__ feed | / \ the trolls| / \ \| / _\ \ -- /|\\ \ || / | | | |\/ || / \|_|_|/ |__|| / / \|| || / | | /|| --| | | |// | --| * _| |_|_|_| | \-/ *-- _--\ _ \ // | / _ \\ _ // |/ * / \_ /- | - | | * ___ c_c_c_C/ \C_c_c_c -- derek :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Brett Parker wrote: > On Mon, Jun 05, 2006 at 03:00:17PM +0300, Ilias Lazaridis wrote: >> James Bennett wrote: >>> Can we declare this thread closed now, >> or course not. >> >> In topic posts subjecting the schema evolution support are of course >> welcome. > > Other than you, which seems to be annoying a lot of people, has anyone > responded *technically* to your posts? You appear to be doing a good job > of not making any friends, here. Well done. At least you admit that my technical thread was spammed with off-topic comments. >>> and ask that anyone who wishes to play with Ilias do so off-list? >>> >>> My inbox thanks you in advance. >> For anyone who wishes to ignore a thread: >> >> http://lazaridis.com/core/eval/filter.html > > *YAWN*. > (1) I don't use Mozilla Thunderbird ok, it's just an example > (2) There are other people that contribute to threads, just > because you get involved doesn't neccessarily mean that I want > to ignore the thread. you are right. > (3) If you actually want to provide a useful reference, provide > a useful reference rather than calling the target audience > "Incapable Species" You have a point here. The link is from the old project, and I have used it without thinking much about. I apologize sincerely. > Also, it appears that your web design skills suck, I am not a web-designer. > and the menu on that page bleeds nastily in to the content. Please, if you like, let me know via private email which browser you use. I have verified the site mainly with Firebird (and a little with IE). > Getting bored now, . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
On Mon, Jun 05, 2006 at 03:00:17PM +0300, Ilias Lazaridis wrote: > > James Bennett wrote: > > Can we declare this thread closed now, > > or course not. > > In topic posts subjecting the schema evolution support are of course > welcome. Other than you, which seems to be annoying a lot of people, has anyone responded *technically* to your posts? You appear to be doing a good job of not making any friends, here. Well done. > > and ask that anyone who wishes to play with Ilias do so off-list? > > > > My inbox thanks you in advance. > > For anyone who wishes to ignore a thread: > > http://lazaridis.com/core/eval/filter.html *YAWN*. (1) I don't use Mozilla Thunderbird (2) There are other people that contribute to threads, just because you get involved doesn't neccessarily mean that I want to ignore the thread. (3) If you actually want to provide a useful reference, provide a useful reference rather than calling the target audience "Incapable Species" Also, it appears that your web design skills suck, and the menu on that page bleeds nastily in to the content. Getting bored now, -- Brett Parker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
James Bennett wrote: > Can we declare this thread closed now, or course not. In topic posts subjecting the schema evolution support are of course welcome. > and ask that anyone who wishes to play with Ilias do so off-list? > > My inbox thanks you in advance. For anyone who wishes to ignore a thread: http://lazaridis.com/core/eval/filter.html . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Can we declare this thread closed now, and ask that anyone who wishes to play with Ilias do so off-list? My inbox thanks you in advance. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
tekNico wrote: >> "This Project is Committed to Users of Open Source Products. It tries to >> save their time, > > ...while wasting the developers' one, right. :-| Developers are free to ignore any threads. And you are free to ignore them, too. >> "The weaknesses of the Open Source Product, the Code Base, the producing >> Project, the surounding Community and the Leadership are transparently >> presented. Users have this way a reduced effort to verify the results." > > I don't think you can actually do that. It's really easy. Potential Users and Evaluators are capable people: http://case.lazaridis.com/multi/wiki/DjangoAudit >> But please refrain from further off topic comments within this clearly >> technical topic. > > *Don't count on it.* B-# of course not. > If there's something that makes me lose my temper, it's someone telling > me what I can and cannot say. I just remind you that your writings are off-topic. This is a technical topic, subjecting a simple schema evolution support that I've implemented for django: http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution > You're a lost cause, goodbye. . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
> "This Project is Committed to Users of Open Source Products. It tries to > save their time, ...while wasting the developers' one, right. :-| > "The weaknesses of the Open Source Product, the Code Base, the producing > Project, the surounding Community and the Leadership are transparently > presented. Users have this way a reduced effort to verify the results." I don't think you can actually do that. > But please refrain from further off topic comments within this clearly > technical topic. *Don't count on it.* B-# If there's something that makes me lose my temper, it's someone telling me what I can and cannot say. You're a lost cause, goodbye. -- Nicola Larosa - http://www.tekNico.net/ Sometimes everyone else is just completely wrong. I want nothing to do with any programmer who would mis-indent their code. If you want to mis-indent your code you are an idiot. If you want idiotic code to be an option you are being absurd. -- Ian Bicking, February 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Brett Parker wrote: > On Mon, Jun 05, 2006 at 01:30:10PM +0300, Ilias Lazaridis wrote: >> Tom Tobin wrote: >>> On 6/4/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: >>>> I've create a simple Schema Evolution Support for Django and I am >>>> working to created a Django Quickstart, which will allow even >>>> unexperienced users to see a django site running within their browsers. >>> Ilias Lazaridis is a known mailing list and Usenet troll, and is >>> therefore being ignored by this community. >> I assume you are the spokesman of this community? >> >> And of all Django Users? > > No, [...] very nice. [...] > Oh, yay... I set of pages on your own site that could say anything... > have you got any references *outside* of your own domain that say that > you're not a troll and that your troll like tendencies are over? Or are > you just expecting it to be taken on faith? Just as any other person posting on this and any other open source user list: I don't have to provide any references to post topic's valid for this list. Please, if you have something to contribute to the technical nature of this thread, let me know. - " I am now focusing to produce results within the Open Source Domain. This Schema Evolutions Support is part of a private project. http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution http://case.lazaridis.com/multi/browser/django/rework/evolve.py http://case.lazaridis.com/multi/browser/django/rework/add_evolvedb_command.diff Perhaps there is some user intrested in using the results and providing some feedback. " . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Jay Parlar wrote: > On 6/4/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: >> This starts to become ridiculous. > > That's your own fault. You've dug a pretty deep grave for yourself, > with your behaviour across various newgroups. You can't blame people > for wanting to dismiss you because of it. > >> I've _implemented_ as simple schema evolution for django, which I need >> for a personal project with a _deadline_. > > And based on your past behaviours, that might just be a result of you > trying to become an even better troll. > > For me, I'll just ignore you from now on. Maybe other people here will > be more accepting of a well known troll. If you really are trying to > change your ways, then best of luck to you, in defeating the persona > you've created for yourself. You've already been dismissed on > django-dev, so my guess is that the odds of any of your work ever > hitting the Django SVN tree are pretty slim. http://lazaridis.com/core/eval/filter.html . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
On Mon, Jun 05, 2006 at 01:30:10PM +0300, Ilias Lazaridis wrote: > > Tom Tobin wrote: > > On 6/4/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > >> I've create a simple Schema Evolution Support for Django and I am > >> working to created a Django Quickstart, which will allow even > >> unexperienced users to see a django site running within their browsers. > > > > Ilias Lazaridis is a known mailing list and Usenet troll, and is > > therefore being ignored by this community. > > I assume you are the spokesman of this community? > > And of all Django Users? No, but given your history, they're giving a good heads up that it's probably worth just ignoring you and your trolling ways... > > Any statements by Ilias > > Lazaridis should be considered incorrect, inaccurate, or otherwise > > tainted with the intention of disrupting conversation on django-users > > and/or django-developers. > > Reference: > > - http://en.wikipedia.org/wiki/Internet_troll > > - http://en.wikipedia.org/wiki/Ilias_Lazaridis > > - http://www.encyclopediadramatica.com/index.php/Ilias > > - http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 > > The "core" project is closed. > > http://lazaridis.com/core/eval/index.html > http://lazaridis.com/core/index.html > http://lazaridis.com/pj/index.html Oh, yay... I set of pages on your own site that could say anything... have you got any references *outside* of your own domain that say that you're not a troll and that your troll like tendencies are over? Or are you just expecting it to be taken on faith? "Thanks", -- Brett Parker --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Steven Armstrong wrote: > On 06/04/06 18:11, Ilias Lazaridis wrote: >> Jay Parlar wrote: >>> Ilias: >>> >>> I thought you would stop bothering Django people after it was revealed >>> on Django-dev that you're a known Internet troll: >> [...] >> >> This starts to become ridiculous. > > What do you expect? That people focus on the technical nature of this thread and the results. > To be honest I actually think some of the things on the page [1] you > posted may be usable. I've implemented a simple schema evolution mechanism, which allows simple incremental design: http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution I need this to start with a personal project, which hopefully will secure me some incoming. > But after posting around like a moron to various developers list and > wasting everybody's time - how can you expect that anybody would take > you or anything that comes from you seriously? I have analyzed software production system, whilst posting valid technical topics to the public discussion media. Everything is documented transparently on my website: http://lazaridis.com/core/index.html http://lazaridis.com/core/eval/index.html > [1] http://case.lazaridis.com/multi/wiki/DjangoProductEvaluation This thread here is about a schema evolution support for django. . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
Tom Tobin wrote: > On 6/4/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: >> I've create a simple Schema Evolution Support for Django and I am >> working to created a Django Quickstart, which will allow even >> unexperienced users to see a django site running within their browsers. > > Ilias Lazaridis is a known mailing list and Usenet troll, and is > therefore being ignored by this community. I assume you are the spokesman of this community? And of all Django Users? > Any statements by Ilias > Lazaridis should be considered incorrect, inaccurate, or otherwise > tainted with the intention of disrupting conversation on django-users > and/or django-developers. > Reference: > - http://en.wikipedia.org/wiki/Internet_troll > - http://en.wikipedia.org/wiki/Ilias_Lazaridis > - http://www.encyclopediadramatica.com/index.php/Ilias > - http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 The "core" project is closed. http://lazaridis.com/core/eval/index.html http://lazaridis.com/core/index.html http://lazaridis.com/pj/index.html - I am now focusing to produce results within the Open Source Domain. This Schema Evolutions Support is part of a private project. http://case.lazaridis.com/multi/wiki/DjangoSchemaEvolution http://case.lazaridis.com/multi/browser/django/rework/evolve.py http://case.lazaridis.com/multi/browser/django/rework/add_evolvedb_command.diff Perhaps there is some user intrested in using the results and providing some feedback. . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
tekNico wrote: >> Your comments are very welcome. > > Wow, man (or whatever you are), you're something. :-) > > You actually cite your detractors on your own pages (see bottom of > http://case.lazaridis.com/multi/wiki/DjangoAudit , and of > http://lazaridis.com/core/eval/index.html ). "This Project is Committed to Users of Open Source Products. It tries to save their time, whilst selecting Open Source Products which comply to Requirements like simplicity, openess, transparency and similar - and which respect the users effort and time." "The weaknesses of the Open Source Product, the Code Base, the producing Project, the surounding Community and the Leadership are transparently presented. Users have this way a reduced effort to verify the results." http://case.lazaridis.com/multi/wiki/ProjectOverview > Maybe you actually *mean* something, and are not trying to troll. In > that case, what would that be? Do you really think someone would fall > for your peculiar marketese, and give you money? > > Or are you really thinking you're doing something (gasp) *useful*? > > I'm bewildered, and a little amused, too. Feel free. But please refrain from further off topic comments within this clearly technical topic. > -- > Nicola Larosa - http://www.tekNico.net/ > > If you can't answer a question within three steps, > you haven't designed the answers right. > -- Dratz, February 2006 . -- http://lazaridis.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
> Your comments are very welcome. Wow, man (or whatever you are), you're something. :-) You actually cite your detractors on your own pages (see bottom of http://case.lazaridis.com/multi/wiki/DjangoAudit , and of http://lazaridis.com/core/eval/index.html ). Maybe you actually *mean* something, and are not trying to troll. In that case, what would that be? Do you really think someone would fall for your peculiar marketese, and give you money? Or are you really thinking you're doing something (gasp) *useful*? I'm bewildered, and a little amused, too. -- Nicola Larosa - http://www.tekNico.net/ If you can't answer a question within three steps, you haven't designed the answers right. -- Dratz, February 2006 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django Quick Start with Schema Evolution Support
On 6/4/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > > I've create a simple Schema Evolution Support for Django and I am > working to created a Django Quickstart, which will allow even > unexperienced users to see a django site running within their browsers. Ilias Lazaridis is a known mailing list and Usenet troll, and is therefore being ignored by this community. Any statements by Ilias Lazaridis should be considered incorrect, inaccurate, or otherwise tainted with the intention of disrupting conversation on django-users and/or django-developers. Reference: - http://en.wikipedia.org/wiki/Internet_troll - http://en.wikipedia.org/wiki/Ilias_Lazaridis - http://www.encyclopediadramatica.com/index.php/Ilias - http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/138966 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
