Joseph Kocherhans wrote: > 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.
I've overflown the document and will provide some feedback within a seperate thread. > You also may want to add SqlAlchemy to your list. It's pretty cool, ok, done: http://case.lazaridis.com/multi/wiki/Persist > 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. The two projects should cooperate a little (in context of their schema evolution subsystems): http://dev.lazaridis.com/base/wiki/CooperationProcess#SubsystemLevel >> 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". I have created additionally a fictional django product. It should become clear that Simplicity and Product-Identity (of the django product) would be increased by this name change: http://case.lazaridis.com/multi/wiki/DjangoProductFictional > Adrian Holovaty is the final word on things like this though. I assume "Adrian Holovaty" is the Django Project Lead? Is there a Team Overview available? >> * 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. The setup for Newcomers and Evaluators would be simplified this way. The resulting possible problems can be solved by several ways (e.g. syncdb creates folder /db/default.db and and absolute path to this file, if necessary). Note: solution suggestion is just given as an example. >> * 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. Ok, I understand that I can do it. But my main intrest is, to have this as a default, thus the definition of multiple databases is possible (dbdevelope, dbtest, dbdeployed). An alternative would be, to allow multiple database configurations within the existent config file. >> * Enable Admin application by default > > This has been discussed and dismissed serveral times already. Comparing with other systems, this admin interface is one of the strongest points of Django. Remember that not every user is able to take all the setup barriers. >> * Create a superuser by default (e.g. user:admin / pass:django) > > -1. The slight convenience doesn't make up for the security implications IMO. The implementation could be e.g. with an command-line option "-s": http://case.lazaridis.com/multi/wiki/DjangoProductFictional#CreatetheDatabase >> * Rename "startapp" to "createapp" > > Once again, name churn. ok >> 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" Of course I could provide an own project skeleton. But my goal is, to select products/projects that care a lot about simplicity/usability and especially "low barrier to entry". An possibility would be, to allow multiple project templates (or skeletons) for "django-admin startproject", e.g. by a 2nd parameter (which would default to the existent project template, thus no breakage is introduced). - As to my "Selection Case Project": "This Project is Committed to Users of Open Source Products." http://case.lazaridis.com/multi/wiki/ProjectOverview >> 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. Ok. I will open a seperate thread on the schema evolution. > Like any open source > project though, we all work for free, so no promises. I think the Django Project has everything to create and provide commercial services around it. The incomings could be used to increase the development speed and quality further. > 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. It is _very_ important, to see the newcomer point of view, which I have presented. > Your quick start looks promising. I hope you keep working on it. I will do so, but it can only write an efficient quick-start if django itself is efficient in context of a 'quick-start'. As mentioned above, the goal is something like this: http://case.lazaridis.com/multi/wiki/DjangoProductFictional [Sidenote: In the past, I had contacted the ruby-on-rails project, pointing out the importancy of a single-file setup. They have reacted, and provided a very simple user entry.] > Joseph Thank you for your thorough comments. . -- http://lazaridis.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
