I did not understand your problem first. I will try to guess it and explain it:
You created a project with another application that also use a model Setting with a ForeignKey to Site and also has not defined a related_name for a ForeignKey field. Is not it? (That can cause the same error.)
I will fix it only by this replace:
- site = models.ForeignKey(Site, verbose_name=_('Site'))
+ site = models.ForeignKey(Site, verbose_name=_('Site'), related_name="livesettings_set")
Lovercase are better than camelCase for field names.
It is not probable that the name "longsetting" causes a conflict for anybody.
In my fork is prepared a new version of livesettings with an applied patch from #24. That compoetely removes the table livesettings_longsetting. (with a migration for South for doin it automatically etc.) Livesettings will have only one table and a model name is not important more.
Ad 4) I can think about long settings again. The necessary condition for retaining longsetting is that the apropriate db table must be known by declared value type before any access to db. Otherwise the current implementation is less effective than future saving everything into TextField. Expect that the application is general enough for everybody and an average user needs less than half of declared settings. Other settings remain on default values. For them is nothing saved to the database. The current implementation is first to query livesettings_setting, then to query livesettings_longsetting and if it is also not found then the default value is used.
Yes, for Postgres CharField and TextField are the same and using only TextField looks pretty good. But it can be another DB system.
Even if every setting will be changed by user, caching still will be helping to decrease payload. So, p4 from my side was not about performance, just a logical issue :)
Removing longsetting allowed to fix many subtle issues that earlier was not possible. E.g. exception handling. It is possible that at loading different models.py, the tables livesetting_* are present, but the command "test" is running and later will be the connection to the normal database closed and replaced to a connection to an new created empty database. Or the initial "syncdb" is running on postgres db with enabled transactions. All access to livesettings must be skipped otherwise all following commands will fail or some structure updates will be hurt by rollback. Everything would be twice more complicated and you must buy twice bigger monitor -:)