Re: New to dj: relational limitations

On Wed, Aug 15, 2012 at 12:48 AM, Axel Rau <Axel.Rau@chaos1.de> wrote:
> Hi,
>
> I'm starting to investigate django while designing a web GUI for an already productive DB.
> 3 applications are currently maintaining the DB contents, one of them is a real-time app (email server), others are periodic background tasks.
> ERM is the central design method
> https://www.chaos1.de/svn-public/repos/network-tools/ERDB/trunk/database/ERD.pdf
> (supplemented by use-case-modelling for the oo code)
> and the implementation is in SQL:2003 (PostgreSQL 9.1):
> https://www.chaos1.de/svn-public/repos/network-tools/ERDB/trunk/database/erdb.sql
> https://www.chaos1.de/svn-public/repos/network-tools/ERDB/trunk/database/dd.sql
>
> I was impressed, how well inspectdb turned my schema into classes (100% automatic) after working around the missing schema concept in dj (I have a operational and a development DB both with a set of identical schemas). (I learned that schemas will be supported in 1.5).>

By way of managing your expectations -- schemas *may* be supported in
1.5. Someone is working on them, but that doesn't mean they are
guaranteed to be in the 1.5 release.

> The next step (after working through the tutorial) was to make some of my tables accessible in the admin site, which exposed some limitations of inspectdb (the SQL standard describes how to get meta data from the INFORMATION SCHEMA, which all RDBMS must implement, in an vendor independent manner):

This SQL "Standard" of which you speak… do you know of anyone that
implements it? :-)

Seriously -- I've spent many years working on Django, and a good chunk
of that time has been spent finding ways to work around the
differences in the SQL "standard" implementations provided by SQLite,
MySQL and PostgreSQL. The fact that the SQL standard says something
should be provided, and should be provided in a particular way, is in
no way a guarantee that an implementation actually provides that
feature in the way described.

> SERIAL was not mapped to AutoField (all my primary keys have either SERIAL or BIGSERIAL),
> no AutoField with BigInteger (AFAICS),
> referential constraint action was not mapped to ForeignKey.on_delete,
> ENUM type not supprted (I found a way to create one as custom field),
> custom types not mapped to their (standard) parent types,

Most of these limitations are an extension of the way Django views the
world. In the vanilla Django usage model, you use your Django model to
generate your SQL tables. The SQL that is exposed is therefore
focussed on those features that you can expose in a meaningful way in
Python code. Python doesn't have a concept of an enumerated type, so
there hasn't been a whole lot of effort focussed on that feature.

If you're coming from a "database first" world, you're going to have a
bit of a bumpy road, mostly due to the leaky abstractions between the
way Django represents models, and the pre-existing expectations of
your database tables.

> but the real stopper was that dj does not support NULL on TEXT columns.

Incorrect. At a model level, you can certainly store NULL in a
TextField column (or any other char-like column for that matter).
However, Django's form tools may not make this easy from a user
interface point of view. For example, in order for the admin to allow
for an "empty" input, you'll need to set the field as 'blank=True',
which means the NULL will be converted to a blank string.

This could be addressed at the form level, but it will involve a
little bit of tinkering (specifically, overriding the to_python method
on django.forms.CharField). However, once you've written a CharField
that treats blanks the way you want, you just need to remember to use
your own form library rather than Django's defaults.

So - the fact that you have a database with a bunch of pre-existing
expectations is going to cause you some difficulties, but they
shouldn't be impossible to overcome. You are, however, going to be
spending some quality time overriding defaults, and getting to know
Django's internals pretty well. :-)

Yours,
Russ Magee %-)

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.