On 5/25/06, lazaridis_com <[EMAIL PROTECTED]> wrote: > > At this point, Django's persistency layer seems intresting, but the > evaluation uncovered a few weaknesses, most importantly the lack of > schema evolution support: > > http://case.lazaridis.com/multi/wiki/DjangoProductEvaluation
Schema evolution support has already been discussed at length. See: http://code.djangoproject.com/wiki/SchemaEvolution but it's not implemented yet. You also may want to add SqlAlchemy to your list. It's pretty cool, although in the early stages of development. There's a Google Summer of Code project just starting to add schema evolution support to SqlAlchemy as well. > Overview of resulting simplification issues: > > * Replace command "django-admin.py" by "django-admin" or "django" > * Replace command "manage.py" by "django" These are kind of appealing to me, but my inner skeptic just screams "name churn". Adrian Holovaty is the final word on things like this though. > * Enable sqlite3 database / filename by default I personally wouldn't want this. Where do you propose putting the database file? I *always* use absolute paths for sqlite db's. If you use relative paths, it's relative to your current directory, not relative to the location of the settings file. This could get really confusing for newbies if they execute manage.py from a different working directory. > * Externalize database settings (e.g. dbdefault.py) You can do this already... that's the beauty of using python for settings. Just import * or whatever from the appropritate module in your main settings file. > * Enable Admin application by default This has been discussed and dismissed serveral times already. > * Create a superuser by default (e.g. user:admin / pass:django) -1. The slight convenience doesn't make up for the security implications IMO. > * Rename "startapp" to "createapp" Once again, name churn. > Solving those Issues would allow to produce a Django-Quick-Start which > could be taken within 5 minutes (+ Installation Effort), which would > allow intrested parties to come quickly in contact with Django. You could provide your own project skeleton that would take care of all of this. There's no real need to change Django to accomplish any of the items above. I'd argue that splitting out the database config makes things *more* complicated. Part of the beauty of django is that it doesn't (in the paraphrased words of someone else, I forget who) "shit all over your filesystem like rails" > I would be intrested to creat a skeleton for the "Database Schema > Evolution" (I have implemente a very simply one for a Ruby ORM). See the link above. > To do so, I would need some feedback from the developers list. > > Can I rely on this? People are generally pretty helpful, but skeptical here. You generally need code and use cases to back up your ideas. Like any open source project though, we all work for free, so no promises. Thanks for taking the time to write all of this up. Everyone here pretty much has the current way things work engrained in our brains at this point and it's nice to see other perspectives. Your quick start looks promising. I hope you keep working on it. Joseph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~----------~----~----~----~------~----~------~--~---
