and i would be said SoC applicant. :)
Kenneth Gonsalves wrote:
> On Thursday 25 May 2006 10:43 pm, Joseph Kocherhans wrote:
>> Schema evolution support has already been discussed at length.
>> See: http://code.djangoproject.com/wiki/SchemaEvolution but it's
>> not implemented yet.
>
> there is
jeroen, brant, ilias, etc:
schema evolution was an idea suggested and specifically granted for the
SoC project. i don't know who here was involved with ranking the
proposals, but for better or worse mine was accepted. to a certain
extent i expect this to come with a effort not to trivialize my
oen:
not miffed. just marking a little tree in a big forest. :)
Todd O'Bryan wrote:
> On May 29, 2006, at 11:09 AM, Derek Anderson wrote:
>
>> schema evolution was an idea suggested and specifically granted for
>> the
>> SoC project. i don't know who here wa
and now: http://en.wikipedia.org/wiki/Ilias_Lazaridis
Carlo C8E Miron wrote:
> On 6/2/06, Julian 'Julik' Tarkhanov <[EMAIL PROTECTED]> wrote:
>> I would advise all respected Django contributors to follow the path
>> mentioned here:
>>
>> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk
the problem is that there are multiple types of escaping. sql? html?
javascript? new-web-tech-of-the-day? do you escape them all, or just some?
personally, i don't like my framework to auto-munge my data behind my
back. esp. in ways that are not clearly defined and could change on a
whim. t
e file type.
Simon Willison wrote:
> On 14 Jun 2006, at 14:44, Derek Anderson wrote:
>
>> the problem is that there are multiple types of escaping. sql? html?
>> javascript? new-web-tech-of-the-day? do you escape them all, or
>> just some?
>>
>> personally, i
subject line says it all - i want your models! :)
if it's obvious what the change is with a comment, that's fine. if not,
before and after versions would be appreciated. i'd like everything
from the mundane to the esoteric.
to avoid flooding the list, you can send them directly to
[EMAIL PROT
hey matt,
would you be willing to send me a copy of your app, your original
schema, and whatever load script failed?
derek
Matthew Flanagan wrote:
> I had some to make some changes to some models today that would result
> in schema changes so I decided to give the schema-evolution branch a
> g
i merged with head before i checked it in. unless i really frelled up
w/ svn, it should only be ~2 weeks behind.
could you send just your models? (+ load script, original schema)
Matthew Flanagan wrote:
> Derek,
>
> On 31/08/06, Derek Anderson <[EMAIL PROTECTED]> wro
which backend are you using?
Matthew Flanagan wrote:
> Derek,
>
> I have manually merged the trunk into my local working copy of the
> schema-evolution branch and started playing with it. I wanted to
> question the SQL "sqlevolve" is outputting. I have this model in an
> application called "asse
gt; On 9/14/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>> postgresql
>>
>> On 14/09/06, Derek Anderson <[EMAIL PROTECTED]> wrote:
>>> which backend are you using?
>>>
>>> Matthew Flanagan wrote:
>>>> Derek,
>>>>
mp_src/
$ svn merge http://code.djangoproject.com/svn/django/trunk
[help message]
god i miss cvs...
Kenneth Gonsalves wrote:
>
> On 26-Oct-06, at 12:40 PM, Derek Anderson wrote:
>
>> can someone who knows svn better than i help me out as to how i would
>> refresh the branch with the latest fro
date with the trunk you just need to run an 'svn log' in
> your working copy and look at the last revision that you merged from
> the trunk, rev xyz say, and use that like this:
>
> svn merge -r xyz:HEAD http://code.djangoproject.com/svn/django/trunk
> etc
>
>
Victor Ng wrote:
> The tests don't look like they're integrated with runtests.py at all.
no, they're standalone.
> 3) Run reset_all_to_pre (note that this doesn't have a shebang at the top)
> 5) Run reset_all_to_post (note that this script also doesn't have a
> shebang at the top)
we're all run
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/m
ngo-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 < ~
e merged to trunk as Django proper.
>>
>> Sebastian Macias
>>
>> On Jul 19, 5:33 pm, Derek Anderson <[EMAIL PROTECTED]> wrote:> Hey all,
>>
>>> Sorry for the double-post, but I've written up some examples /
>>> documentation:
>>&
27;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
actually, "model changes, db needs update" is exactly what i think about
when i think of schema evolution. ;) but seriously...
> * You have to change all your code at once to match the new name
>(evolution is a slow process in nature ;-)
excellent point. for large apps, optionally/tem
s.py and/or your existing database schema
thanks!
derek anderson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups
Russell Keith-Magee wrote:
> - The 'aka' approach has some serious flaws.
for the scenario you give the aka approach (or any formatting of
model+existing_schema+rename_metadata) works just fine. i detail how
(with working examples and sql output) here:
http://kered.org/blog/2007-08-03/schema-
hey all,
is there a way to get runtests.py to run the tests for multiple backends
at a time? right now i'm just editing my settings.py file manually each
time, and wanted to check before i wrote my own script. :)
thanks,
derek
--~--~-~--~~~---~--~~
You receiv
Brantley Harris wrote:
> Your
> philosophy seems to be, "Those problems are spiky edge cases", but I
> think the hope was they would be solved as well, or at least put on
> track for a solution later on.
more like "low-hanging-most-useful-fruit first" :) everyone agrees
that there will never b
Russell Keith-Magee wrote:
> Your approach is predicated on the assumption that migrating
> v1->v2->v3 is equivalent to v1->v3. This is true if you only look at
> renaming, deleting or adding the fields themselves.
so i think i have a cross-over solution. :)
what it boils down to is there are f
Jacob Kaplan-Moss wrote:
> On 8/7/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>> Again - IMHO, the 'aka' syntax is a non-starter (for all the reasons I
>
> Russ is doing a great job speaking for me here, too.
>
> We're currently trying to move non-required metadata *out* of the
> model (c
Russell Keith-Magee wrote:
>> * full migration graphs should be supported, not just linear steppings
>> * a list of known schema fingerprints
>> * a dict mapping (from_fprint,to_fprint) pairs to scripts (lists of
>> sql statements and/or python function calls, to be run in order...think
>> p
i have had this exact situation happen to me before. (rolling out a
change, then another change reversing it) actually several times. i
have NEVER had a scenario where client Y says "can you please make sure
i lose my data?"
your schema integrity in assured. the data integrity is also assu
Mike H wrote:
> Sorry, no. In my simple example, the data is not in the state that the
> developer expected. He asked for the column to be deleted, then
> recreated.
this was brought up when i first designed this for the af. my answer
was: it's pretty obvious when you're returning to an iden
Yuri Baburov wrote:
> 1) How one writes operation to reset all field values to default? Is
> it a migration at all?
just stick an "update mytable set col=value;" in your upgrade script.
(but if you're doing this outside of any schema changes, yes i would
argue that this is not a migration issue
Yuri Baburov wrote:
\> 1) Would the app_name/schema_evolution.py be automatically
generated/updated?
> I don't want to be a monkey copying output of sqlevolve and
> sqlfingerprint to that file. I better remove all parts of file that I
> won't use.
no. i think that those who don't trust introspe
Russell Keith-Magee wrote:
> I thought you were proposing moving away form ordered sequences? Besides:
i am moving towards graphs of schema revisions. but while lines are
always graphs (and graphs can have order), only the simplest graph can
be represented as a line. and graph paths are alwa
Brantley Harris wrote:
> Er, could you re-factoritize your system into a stand-alone app? Then
> it could be added by anyone. That seems like win/win to me.
i considered this. but i have my doubts that i could get the necessary
hooks pushed through to allow this to function as an external app
Jacob Kaplan-Moss wrote:
> So what hooks do you think you'd need? Would the sql-level hooks being
> discussed in other threads be sufficient?
would you allow a hook for still annotating in models.py?
derek
--~--~-~--~~~---~--~~
You received this message because y
> In short, Django was not *designed* to be threadsafe, but any obvious
> problems that I'm aware of have been fixed. YMMV.
that's scary.
but then again, python itself isn't multi-threaded. (all threading is
faked - google "global interpreter lock". lazy s.o.b. python devs) so
all your rea
you mean to say cooperative multithreading, right?
if so, heck yeah. dear lord in heaven yeah.
Nicola Larosa wrote:
> Derek Anderson wrote:
>> but then again, python itself isn't multi-threaded. (all threading is
>> faked - google "global interpreter lock"
ostly i/o). they're like green threads from
java 1.0. "faked" is about as good of an adjective as you get.
still love python tho.
derek
Fredrik Lundh wrote:
> Derek Anderson wrote:
>
>> but then again, python itself isn't multi-threaded. (all threading is
>
SmileyChris wrote:
> I like Derek's take on model comparison using introspection, but
> really think that it should be based on a migration system. I know
> several Django developers agree with me on this (including Russell).
i see them as two distinct, non-exclusive tasks, with automatic
intros
ok, for the official status:
as mentioned earlier, yuri and i are joining forces on
introspection-driven schema evolution. and since automatic
introspection is so controversial (and obviously a poison pill for
acceptance into django-proper), we've rewriting it as an external library.
the pro
Russell Keith-Magee wrote:
> I'm not sure where you got the idea that automatic introspection is
> the issue - the proposal I put forward included automatic
> introspection. The issue has always been the aka syntax, and the
> consequences of that syntax on the overall design.
because several of t
re is nothing on how to actually generate
these mutations, except for the suggestion of calling it "syncdb --hint"
(instead of "sqlevolve" i presume). is it up to the user to write them?
where is the actual introspection/generation bit?
derek
Russell Keith-Magee w
Russell Keith-Magee wrote:
> On 9/27/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> russell, i've re-read your linked email (from 8/4/07), and i'm still
>> totally lost as to what you're proposing. i'm reading of application
>>
Russell Keith-Magee wrote:
> The latter, by comparing the signature of the models.py that you have
> with the signature in the Evolution table. The evolution table
> contains the signature of the last model that was sync'd; if this
> doesn't correspond to the current model, you need migrations to
Russell Keith-Magee wrote:
> It's not the _model_ per se - just a rendition of the significant data
> in the model.
a rose by any other name (but yes, i assumed you meant not the
actual textual rendition, but a data structure containing all the
database-relevant attributes of the model)
>>
Paul Davis wrote:
>
> As near as I can tell these are the main issues that don't seem to be
resolved:
>
> 1. Balancing ease of use with power of use (Ie, Alice vs. Carol)
> 2. Level of versioning: Model vs. Application vs. Entire database
> 3. Application of versions: v1 -> v2 -> v3 =? v1 -
Paul Davis wrote:
>
> As near as I can tell these are the main issues that don't seem to be
> resolved:
>
> 1. Balancing ease of use with power of use (Ie, Alice vs. Carol)
> 2. Level of versioning: Model vs. Application vs. Entire database
> 3. Application of versions: v1 -> v2 -> v3 =? v1 ->
u and
ben" deciding between yourselves what you think is best...and then some
sort of wild-west-style publicity shootout.
to the other people who have weighed into this discussion...am i alone
thinking along these lines?
derek
Russell Keith-Magee wrote:
> On 9/28/07, Derek Anderson <[
hey marty,
i agree. see:
http://code.djangoproject.com/wiki/SchemaEvolutionDocumentation
maybe another day or two for the stand-alone version...
derek
Marty Alchin wrote:
> I won't get into the discussion on features or implementation yet, but
> I do have to agree that working code speaks vo
Django External Schema Evolution Branch
===
http://code.google.com/p/deseb/
I've released v0.2, which supports both MySQL and Postgresql, and works
with both django-head and django-v0.96.
This release contains the introspection/generation code only. The
"sc
t -
> especially if we limit ourselves to versions >=7.4 - I am happy to help
> in this area.
i'll take any suggestions you have. :)
thanks,
derek
Nis Jørgensen wrote:
> Derek Anderson skrev:
>> Django External Schema Evolution Branch
>> =
me the difference
between the two and we can, i would love to merge them alltogether.
derek
Nis Jørgensen wrote:
> Derek Anderson skrev:
>> hey nis,
>>
>> 1) psycopg2 has been added as a backend
>>
> Any reason for not using my code (importing postgresql.py f
cool. looks like nothing that'll effect us. i've switched back to one
common postgresql backend.
danke. :)
Yuri Baburov wrote:
> 2007/10/3, Derek Anderson <[EMAIL PROTECTED]>:
>> yes, because that is what django does with it's psycopg2 backend. (or
>> a
hey,
what are thoughts on a new option to sqlreset (and others, as
appropriate) to apply the change to the db? something like this:
./manage.py sqlreset --apply
just as a time saver. i'd write the patch if no one's opposed.
derek
--
looking to buy or sell anything?
try: h
to managed-migrations.)
Russell Keith-Magee wrote:
> On 10/19/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> Russell Keith-Magee wrote:
>> as was somewhat the intent of the question. :) i was trying to figure
>> out of there's an existing style i should mode
Russell Keith-Magee wrote:
> (sql)reset is broken as currently implemented, and as far as I can
> make out, it can't really be fixed without some major changes.
> However, I'm not convinced it is worth spending the effort to fix the
> problems that exist. The problem (sql)reset is intended to solv
are column defaults not supposed to be set by django under postgres?
see:
$ ./manage.py sql auth
BEGIN;
[...]
CREATE TABLE "auth_user" (
"id" serial NOT NULL PRIMARY KEY,
"username" varchar(30) NOT NULL UNIQUE,
"first_name" varchar(30) NOT NULL,
"last_name" varchar(30) NOT NU
i had thought they werebut it appears i am wrong.
may i ask the core devs: why?
derek
Yuri Baburov wrote:
> 2007/10/24, Derek Anderson <[EMAIL PROTECTED]>:
>> are column defaults not supposed to be set by django under postgres?
> yes, correct
> defaults are ne
ah, ok. danke.
Jacob Kaplan-Moss wrote:
> On 10/23/07, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> are column defaults not supposed to be set by django under postgres?
>
> Django doesn't set defaults in the database at all.
>
> The basic reason is that too
what, no schema evolution? =p
(ducks for cover behind fire-retardant suit ;)
Adrian Holovaty wrote:
> (I've been saving this e-mail since the last sprint. Given that we're
> sprinting again this weekend, I figured it was about time to get this
> conversation started.)
>
> Let's get a definiti
twas a joke. i don't think any of the authors of any of the evolution
mechanisms believe their implementations ready to be included into v1.0.
(my own included :)
Adrian Holovaty wrote:
> On Nov 30, 2007 11:56 AM, Derek Anderson <[EMAIL PROTECTED]> wrote:
>> what, no s
even if it was possible, i don't think it's what you would really want.
logically, this would return an indefinite number of records,
somewhere between 0 and 10, depending on what's in your table, not the
first 10 records of people who's name starts w/ an 'a'.
why are you not doing this?
U
i *would* like to champion this, as django's regex -> function mapping
is its best single feature, IMO.
to reuse a well-known axiom: "those who don't know regular expressions
are doomed to reinvent them... poorly"
derek
Rob Hudson wrote:
> Just a note: I'm not going to champion this one sinc
61 matches
Mail list logo
