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
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
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
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
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
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
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
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
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
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
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
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
>> =
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
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
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 <[
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 -
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)
>>
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:
> 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
>>
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:
> 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
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
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
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
>
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"
> 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
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
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
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
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
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
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
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
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
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:
> 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
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
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
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-
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
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
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
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:
>>&
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 < ~
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
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
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
>
>
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
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,
>>>>
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
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
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
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
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
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
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
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
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
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
61 matches
Mail list logo
