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.
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. 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. Am I correct that varchar2 is always preferred to NCLOB where appropriate? >> 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. If we'll settle on a good enough solution, of course. -- Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, MSN: bu...@live.com -- 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.
