case-sensitive fields/columns in models

Create issue
Issue #1098 new
Tay Ray Chuan created an issue

We still have a few running around.

{{{ $ grep -ERn "[a-z][A-Z][^ =]+ =" . payment/ optionName = PaymentChoiceCharField(("Option Name"), max_length=20, payment/ sortOrder = models.IntegerField(("Sort Order")) payment/💯 decryptedCC = property(decryptCC) payment/ expirationDate = property(_expireDate) product/ allowedUses = models.IntegerField(("Number of allowed uses"), product/ numUses = models.IntegerField(("Number of times already used"), product/ minOrder = CurrencyField(("Minimum order value"), product/ startDate = models.DateField(("Start Date")) product/ endDate = models.DateField(("End Date")) product/ allValid = models.BooleanField(("All products?"), default=False, product/ minOrder = self.minOrder or 0 product/ taxClass = models.ForeignKey('TaxClass', verbose_name=('Tax Class'), blank=True, null=True, help_text=("If it is taxable what kind of tax?")) product/ numProcessed = 0 product/ optionDict = dict([(sub.option_group.sort_order, sub) for sub in self.options.all()]) product/ if numProcessed == self.options.count(): product/ groupList = [] satchmo_store/shop/ numItems = 0 satchmo_store/shop/ numItems = property(_numItems) satchmo_store/shop/ itemCount = 0 satchmo_store/shop/ numItems = property(_get_count) satchmo_store/shop/ alreadyInCart = False satchmo_store/shop/ looksTheSame = len(details) == similarItem.details.count() satchmo_store/shop/ looksTheSame = False satchmo_store/shop/ alreadyInCart = True satchmo_store/shop/ taxProcessor = get_tax_processor(self) tax/modules/area/ taxClass = models.ForeignKey(TaxClass, verbose_name=('Tax Class')) tax/modules/area/ taxZone = models.ForeignKey(AdminArea, blank=True, null=True, tax/modules/area/ taxCountry = models.ForeignKey(Country, blank=True, null=True, tax/modules/us_sst/ taxClass = models.ForeignKey(TaxClass, verbose_name=('Tax Class')) tax/modules/us_sst/ taxZone = models.ForeignKey(AdminArea, blank=True, null=True, tax/modules/us_sst/ taxCountry = models.ForeignKey(Country, blank=True, null=True, tax/modules/us_sst/ isTaxable = models.BooleanField(verbose_name=('Taxable?'), default=True, ) tax/modules/us_sst/ useIntrastate = models.BooleanField(verbose_name=('Use Intrastate rate instead of Interstate?'), tax/modules/us_sst/ useFood = models.BooleanField(verbose_name=('Use food/drug rate instead of general?'), tax/modules/us_sst/ jurisdictionType = models.IntegerField(max_length=2, choices=JURISDICTION_CHOICES, tax/modules/us_sst/ jurisdictionFipsCode = models.CharField(max_length=5, tax/modules/us_sst/ generalRateIntrastate = models.DecimalField(max_digits=8, decimal_places=7, tax/modules/us_sst/ generalRateInterstate = models.DecimalField(max_digits=8, decimal_places=7, tax/modules/us_sst/ foodRateIntrastate = models.DecimalField(max_digits=8, decimal_places=7, tax/modules/us_sst/ foodRateInterstate = models.DecimalField(max_digits=8, decimal_places=7, tax/modules/us_sst/ startDate = models.DateField(verbose_name=('Effective Start Date')) tax/modules/us_sst/ endDate = models.DateField(verbose_name=('Effective End Date')) tax/modules/us_sst/ recordType = models.CharField(max_length=1, choices=TAX_BOUNDRY_CHOICES, tax/modules/us_sst/ startDate = models.DateField(verbose_name=('Effective Start Date')) tax/modules/us_sst/ endDate = models.DateField(verbose_name=('Effective End Date')) tax/modules/us_sst/ lowAddress = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ highAddress = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ oddEven = models.CharField(max_length=1, blank=True, null=True, choices=ODD_EVEN_CHOICES, tax/modules/us_sst/ streetPreDirection = models.CharField(max_length=2, blank=True, null=True, tax/modules/us_sst/ streetName = models.CharField(max_length=20, blank=True, null=True, tax/modules/us_sst/ streetSuffix = models.CharField(max_length=4, blank=True, null=True, tax/modules/us_sst/ streetPostDirection = models.CharField(max_length=2, blank=True, null=True, tax/modules/us_sst/ addressSecondaryAbbr = models.CharField(max_length=4, blank=True, null=True, tax/modules/us_sst/ addressSecondaryLow = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ addressSecondaryHigh = models.IntegerField(max_length=8, blank=True, null=True, tax/modules/us_sst/ addressSecondaryOddEven = models.CharField(max_length=1, blank=True, null=True, tax/modules/us_sst/ cityName = models.CharField(max_length=28, blank=True, null=True, tax/modules/us_sst/ zipCode = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ zipCodeLow = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ zipExtensionLow = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ zipCodeHigh = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ zipExtensionHigh = models.IntegerField(blank=True, null=True, tax/modules/us_sst/ serCode = models.CharField(max_length=5, verbose_name=('Composite SER Code'), blank=True, null=True) tax/modules/us_sst/ fipsStateCode = models.CharField(max_length=2, blank=True, null=True, tax/modules/us_sst/ fipsStateIndicator = models.CharField(max_length=2, blank=True, null=True, tax/modules/us_sst/ fipsCountyCode = models.CharField(max_length=3, blank=True, null=True, tax/modules/us_sst/ fipsPlaceCode = models.CharField(max_length=5, blank=True, null=True, tax/modules/us_sst/ fipsPlaceType = models.CharField(max_length=2, blank=True, null=True, tax/modules/us_sst/ useIntrastate = None tax/modules/us_sst/ useFood = None tax/modules/us_sst/ if self.recordType == 'Z': tax/modules/us_sst/ elif self.recordType == '4': tax/modules/us_sst/ taxRate = models.ForeignKey(TaxRate, verbose_name=('Tax Rate')) tax/modules/us_sst/ useIntrastate = models.BooleanField(verbose_name=('Use Intrastate rate instead of Interstate?'), tax/modules/us_sst/ useFood = models.BooleanField(verbose_name=('Use food/drug rate instead of general?'), }}}

Almost 70+ offending fields.

Should we do something about them?

Comments (3)

  1. Chris Moffitt repo owner

    (Reply via

    This is a good question. I don't know that the field names are causing issues. It had to do more with table names.

    Unless someone has a really big problem, I don't want to make this big a change. I would suspect if others had noticed this issue we would have heard about it by now.

  2. John-Scott Atlakson

    It does make it a pain when working from dbshell to have to remember to manually quote certain field names in PostgreSQL. Some of the above are just method/attribute/variable names and not actual db fields. Excluding these and the last three lines from the commented out TaxCollected model there are 53 camel-cased model field names.

    The more Pythonic and Django-like Satchmo gets and less idiosyncratic, the easier it is to use. I would +1 this change for 1.0. After 0.9.1-final is released I could help with the South migrations if need be, but I would really like to remove the camel-case where it does not belong.

  3. Hynek Cernoch

    about these CamelCases

    It is easy to remember that these are limited only to fields related to tax, discounts and payment.

    Most of these are internals of modules tax.modules.area and tax.modules.us_sst which are not part of default configuration and even when added to, are never accessed directly from the Satchmo core, only via processor methods.

    Other tables are: payment_paymentoption, payment_creditcarddetail, product_discount and product_product. The field product.taxClass is to be good remembered, because it is probable it can be used in some user code and a temporary backward compatible alias attribute should be provided, not only rename it.

    about changes and South

    Please, do not change the database until the following is resolved. (planned version numbers are not the essentials) Take into account, what is now written in the documentation:

    "The ideal way to migrate would be to dump all of your existing store data, remove all of your old tables, synch the new models and reload the data." (docs/migration.txt)

    This is a pure alibism. (or ideal is meant theoretical not perfect or excellent) Data reload is as complicated or even more than to change the stucture of database with data via writing sql. This is much more important than some CamelCase.

    South has these big problems now: (imho)

    • South can not be enabled at Satchmo installation because of fixtures problems of South.
    • There is no easy a safe method how to detect migration version used some month ago after Satchmo installation, especially if Satchmo has already been upgraded in middletime or migration code had bugs in the time of installation or delay or the changes was minor like adding an index, newertheless obstructing using of an particular migration in the series.
    • The option "--fake" is not a standard unchallenged credible way of activating South. An activating of actual South 0.7.3 (or an older installed) by user, when upgraging to hypothetical Satchmo 1.0, would be a big user problem.
  4. Log in to comment