On 5/11/07, Thomas Guettler <[EMAIL PROTECTED]> wrote: > First I missing a way to sync the database with the model. The command > syncdb has a bad name. It should be called initdb. But you can live > without autosync: Redirect the output of sqlall to a file. Update model, > redirect the output again, and then "diff old.sql new.sql" shows > you what you need to execute in a sql shell (ALTER TABLE ... (ALTER|DROP|ADD) > COLUMN ...)
This is a frequently-asked-for feature, but to date no-one's stepped up and produced a solid implementation of schema evolution with a commitment to maintain it; unless someone's willing to write and maintain quality code for it, it probably won't happen. > I am sorry, but I don't like the template language. I have no problem to > have HTML in python code. That's OK :) People seem to either love or hate the Django template system; having it not be a real programming language is an explicit design goal, but nothing stops you picking a different Python template system and using it instead. > But: This form does not look as goog as the admin interface. > Example: A DateField does not have the Calendar Popup. I found no > way to add this (class="vDateField"). The admin calendar shortcut isn't really designed to be used outside the admin; it relies on the HTML structure of the admin templates. For projects at work I've developed JavaScript widgets for general-purpose use, and it's not terribly hard. > If I understood it right, you should set null=True for FloatField and > DateField (and not blank=True) if it is optional. The newforms library > does not handle this correct. If there is no blank=True in the model, > it complains (ignores null=True). If I use blank=True the sql insert fails, > since the empty string is not a valid date. The 'blank' and 'null' options seem to trip a lot of people up at the start, but I'm not honestly sure what can be done to improve that; having them be two separate options -- one for user interface validation, and one for database-level validation -- is the only way to enable certain types of uses, and various "one should imply the other" proposals all run up against that obstacle. > TEMPLATE_STRING_IF_INVALID: The zen of python: "Errors should never pass > silently.". I want an exception if the template can't resolve a variable. "Unless explicitly silenced." Django goes out of its way to advertise that certain types of template errors will result in an empty string rather than an exception (and note that many exceptions only get "silenced" when DEBUG = False). The reasoning behind this is that, in production, it's often better to have an empty string come back to the template than to have your entire site go down. > Introspection: How to get all fields of a model instance? I discovered > obj._meta.fields. Is this an offical API? Django uses it internally to do introspection, but we haven't yet gotten to documenting it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
