On Fri, Nov 27, 2009 at 3:22 PM, Yuri Baburov <burc...@gmail.com> wrote: > Hi Russell, > > On Thu, Nov 26, 2009 at 1:47 PM, Russell Keith-Magee > <freakboy3...@gmail.com> wrote: >> On Wed, Nov 25, 2009 at 4:24 PM, Yuri Baburov <burc...@gmail.com> wrote: >>> Hi Russell, >>> >>> is it possible to introduce some new field type >>> ShortTextField for that purpose, that will be by default >>> `varchar(4000)` on Oracle and DB2 who supports long varchars, and >>> `text` on other backends like it was before, excepting 'smalltext' >>> instead of 'longtext' for mysql? >> >> I can see that this approach doesn't have any backward compatibility >> issues. However, from a documentation point of view, explaining the >> difference between a ShortTextField and a TextField requires a leaky >> abstraction (i.e., you have to know about implementation details in >> order for the explanation to make sense). >> >> With a different coat of paint, it might be more palatable. A name >> like ShortTextField presupposes the storage implementation, but tells >> you nothing about the appropriate usage. However, a different name - >> something like GenericKeyField tells you nothing about the storage, >> but does tell you when it might be appropriate to use it. >> >> Of course GenericKeyField has the problem of being easy to confuse >> with GenericForeignKey. For that reason, I'm not sold on >> GenericKeyField as a name - any suggestions in this general vein are >> welcome. > First, since we have a lot of fields already like > PositiveIntegerField, there is no problem to add one more specific > field. It's not new kind of fields distinction, it's just one more > specie of them.
PostiveIntegerField isn't a good example here - in fact, it reinforces my point. PositiveIntegerField tells you nothing concrete about the underlying storage - all it describes is a validation condition. > But then much more general problem arises: use of CLOB instead of > varchar2 where 255<length<=4000. > To support Oracle, all Django programmers should now be aware of this > Oracle-specific data type distinction, should know that SmallTextField > is better than TextField for some situations, etc. > That's awful. Agreed. That's why I don't like the idea of adding (Short|Small)TextField. However, if you step away from calling it a TextField, and give it a semantic purpose - storing a Generic Key - then it isn't confusing at all. If you want to store a generic key, use a GenericKeyField. If you want to store text, use a TextField. > So the enhanced idea appears: > TextField(max_length=x) where x<=4000 to be treated as varchar2(x) in Oracle. > TextField with greater length and TextField without length to be > treated as NCLOB. > > LogEntry.object_id rewritten as TextField(max_length=4000). > Documented as a restriction by design, that prevents bad usages. > > This should be documented in Oracle backend docs on data types in bold. I'm not wild about the idea of having underlying datatypes change based on attributes in a field definition. To date, Django has maintained a clear mapping between Field type and database type. > Am I correct that varchar2 is always preferred to NCLOB where appropriate? On this point I would need to defer to our friendly community Oracle experts. >>> I think this is a point where "TextField is accessed by value" >>> abstraction breaks, and better separation between long string and >>> referenced object should be introduced. >> >> Agreed. >> >>> I assume we have not much Oracle & DB2 users yet, and nothing will >>> change for them unless they already suffer from this problem and they >>> will not anymore. Migration script is single "alter table" command, >>> and that needs to be documented. >> >> I'm always a little nervous about upgrading instructions, and doubly >> so about those that include database migrations. History has shown us >> that it doesn't matter how well we write upgrading notes - backwards >> incompatible changes cause problems. Unless there is a particularly >> compelling reason to change the existing Oracle implementation, I'd >> rather not force that change. > Yes, they are always a pain, but in such situation I'm feeling like in > a surgeon. > I tend to prefer to do surgery once instead of living with constant pain. > For this problem, pain is not strong, but surgery is quick, and those who use > newer Django won't even know about that pain. Django has a very firm backwards compatibility guarantee. We are very careful that when we roll out a new version, it doesn't break any existing installations because of changes in documented interfaces. Even if you take one of the biggest changes in Django's post 1.0 history - CSRF support - it has been added in such a way that any existing installation shouldn't be affected by upgrading from 1.1 to trunk. Unfortunately, absent of a schema migration system built into Django, there simply isn't any way to handle changes to model definitions for existing Django tables in a completely transparent way. Documenting changes like this just doesn't cut it - the bad publicity generated by "code broke when I upgraded" isn't mitigated by saying "but it says do X in the documentation". The "cure" administered by the surgeon may be simple, obvious, and right; but if it isn't completely transparent, I'm afraid you're going to have an uphill battle to convince me it's the right solution. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
