Re: Proposed Field API additions

On 11/06/12 10:27, Anssi Kääriäinen wrote: > All of the above sounds good - my main worry was that if you subclass > a field, then it will not get a rule match as the module path prefix > will be different than the parent field's. I don't know if this is an > issue even in South... But if the rule

Re: Proposed Field API additions

On 11 kesä, 11:49, Andrew Godwin wrote: > On 10/06/12 21:54, Anssi K ri inen wrote: > > > I agree the needed_fields.py idea was bad. One part of the idea was > > that you would get immediately broken migrations if you remove a > > field. Do all the migrations break if you have a broken field > > r

Re: Proposed Field API additions

On 10/06/12 21:54, Anssi Kääriäinen wrote: > I agree the needed_fields.py idea was bad. One part of the idea was > that you would get immediately broken migrations if you remove a > field. Do all the migrations break if you have a broken field > reference, or only when you actually use a migration

Re: Proposed Field API additions

On 9 kesä, 13:37, Andrew Godwin wrote: > Eugh, autogenerated python files full of imports? Plus, you'd > potentially need more than one (for different migration versions), and I > don't see what improvement this is over full paths, which is what Luke > proposed, what South currently does, and it w

Re: Proposed Field API additions

On 08/06/12 20:01, Anssi Kääriäinen wrote: > On 8 kesä, 19:42, Carl Meyer wrote: >> Yuck. I am not at all convinced that this cure isn't worth than the >> disease. In every case where Django has introduced flattened >> pseudo-namespaces in place of Python's existing namespace system, I think >> it

Re: Proposed Field API additions

On 08/06/12 17:42, Carl Meyer wrote: > Hi Andrew, > > On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and keyword arguments you would >

Re: Proposed Field API additions

On 08/06/12 16:45, Jacob Kaplan-Moss wrote: > Hi Andrew -- > > Generally I'm +1, and I think I see the point pretty clearly. Just a > couple of questions: > > On Thu, Jun 7, 2012 at 7:17 PM, Andrew Godwin wrote: >> - Requiring that all fields expose a method which says how to >> reconstruct the

Re: Proposed Field API additions

On 08/06/12 16:16, Anssi Kääriäinen wrote: > I did a little digging into South code, and I think I now understand > the needs. Basically, when you migrate a model, you might need to read > the database data by using the old model definitions. You can't use > the currently installed model definition

Re: Proposed Field API additions

On 08/06/12 18:16, Michael Manfre wrote: > > > On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote: > > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor up

Re: Proposed Field API additions

On 8 kesä, 19:42, Carl Meyer wrote: > Yuck. I am not at all convinced that this cure isn't worth than the > disease. In every case where Django has introduced flattened > pseudo-namespaces in place of Python's existing namespace system, I think > it's come back to bite us later. > > How bad is it

Re: Proposed Field API additions

On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote: > > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor updates. Some SQL is quite > complicated and dubiously rela

Re: Proposed Field API additions

Hi Andrew, On Thursday, June 7, 2012 11:17:51 AM UTC-6, Andrew Godwin wrote: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and keyword arguments you would > have to pass into the constructor to make the field ag

Re: Proposed Field API additions

On Fri, Jun 8, 2012 at 8:45 AM, Jacob Kaplan-Moss wrote: > Can't this be done by auto-discovering subclasses of Field > (Field.__subclasses__)? Unfortunately, __subclasses__() doesn't work down through the whole hierarchy, just one level deep. So unless we plan to walk the tree to find them all,

Re: Proposed Field API additions

Hi Andrew -- Generally I'm +1, and I think I see the point pretty clearly. Just a couple of questions: On Thu, Jun 7, 2012 at 7:17 PM, Andrew Godwin wrote: >  - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the positional and keyword

Re: Proposed Field API additions

n 8 kesä, 00:20, Andrew Godwin wrote: > On 07/06/12 21:56, Anssi K ri inen wrote: > > > Is the reason for this to be able to track changes to field by > > checking if its init arguments have changed? Why is it not possible to > > track changes by checking the SQL output the field will generate > >

Re: Proposed Field API additions

On 07/06/12 21:56, Anssi Kääriäinen wrote: > Is the reason for this to be able to track changes to field by > checking if its init arguments have changed? Why is it not possible to > track changes by checking the SQL output the field will generate > instead? This is guaranteed to be a string, and s

Re: Proposed Field API additions

On Jun 7, 11:44 pm, Anssi Kääriäinen wrote: > I don't see the difference between doing the registration > automatically by Field.__new__() and automatically registering > anything living in fields.py or fields module. OK, now I get it - you will see in which app the field lives by in which app th

Re: Proposed Field API additions

On Jun 7, 11:16 pm, Alex Ogier wrote: > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor updates. Some SQL is quite > complicated and dubiously related to the particular field, s

Re: Proposed Field API additions

On Thu, Jun 7, 2012 at 3:56 PM, Anssi Kääriäinen wrote: > On Jun 7, 8:17 pm, Andrew Godwin wrote: >> Hi everyone, >> >> As part of my planning for adding schema alteration/migrations into >> Django proper, I need to make a few changes to Fields to allow for >> better serialisation of model defini

Re: Proposed Field API additions

On Jun 7, 8:17 pm, Andrew Godwin wrote: > Hi everyone, > > As part of my planning for adding schema alteration/migrations into > Django proper, I need to make a few changes to Fields to allow for > better serialisation of model definitions (pretty much a requirement for > any change-detecting migr

Re: Proposed Field API additions

On 07/06/12 20:14, Alex Gaynor wrote: > > > On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin > wrote: > > > In particular, I propose: > > - Requiring that all fields expose a method which says how to > reconstruct them. > > Essentially, it returns the pos

Re: Proposed Field API additions

2012/6/7 Andrew Ingram : > On 7 June 2012 18:17, Andrew Godwin wrote: >> This means either having to register custom fields (like admin classes, >> for example), or requiring fields to live in a fields.py or fields >> package (like models and models.py). This is to provide for a >> less-fragile wa

Re: Proposed Field API additions

On Thu, Jun 7, 2012 at 12:17 PM, Andrew Godwin wrote: > Hi everyone, > > As part of my planning for adding schema alteration/migrations into > Django proper, I need to make a few changes to Fields to allow for > better serialisation of model definitions (pretty much a requirement for > any change

Re: Proposed Field API additions

On 7 June 2012 18:17, Andrew Godwin wrote: > This means either having to register custom fields (like admin classes, > for example), or requiring fields to live in a fields.py or fields > package (like models and models.py). This is to provide for a > less-fragile way of referring to them than the

Proposed Field API additions

Hi everyone, As part of my planning for adding schema alteration/migrations into Django proper, I need to make a few changes to Fields to allow for better serialisation of model definitions (pretty much a requirement for any change-detecting migrations system). In particular, I propose: - Requi