Re: Multi-db: Change DatabaseWrappers to no longer be local?
JP wrote: > Looking back over the multi-db branch today, I realized that it seems > to be duplicating the thread locality of connections. The connection > management classes in multi-db django.db manage all connections as > thread local, and the DatabaseWrapper classes in the backends are all > subclasses of local. > > I may be missing something, but I think the latter locality can be > safely removed in multi-db. I didn't look how exactly multi-db branch manages connection so my question may be dumb, sorry. If you intend remove the inheritance of DatabaseWrapper from locals does it mean that when using single DB DatabaseWrappers will be shared between threads? > DatabaseWrappers don't have to be local > because each instance can only be accessed in a particular thread > anyway. I don't exactly understand this bit also. Does it mean that each thread gets its own instance or that threads can access some (shared) instance? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
Hi, I would find already really useful something like a database with, for each project a name, description, type of application (middleware,... or maybe blog, photo manager,...) and a link to the project page (or blog entrance). All this should have a search function. This could replace a lot of the middlewares and other applications that are scattered in the wiki and often hard to find. And could be easy to make it evolve depending of the needs. G On 8/23/06, limodou <[EMAIL PROTECTED]> wrote: > > On 8/23/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > > > limodou wrote: > > > There are some threads talking about the apps repository already, but > > > till now, no repository be found. So I want to suggest again: we > > > should build an official project web site to host django apps or > > > projects. So we can easy share our source code and exchange our ideas. > > > And I think 0.95 is stable enought, and why we still need to wait 1.0, > > > if there is an official web site to host these things, we can reuse > > > others source code easily and make django more improvement I think. > > > > I think this is a great idea. Anyone have suggestions on to how this > > should be organized? > > One big repository or several small ones? > > Everybody with an account has access to all projects or form teams for > > each project? > > Should every project have its own Trac instance? > > > > Separating the projects and forming teams would be more of a Django > > mini-SourceForge, and while this might be ideal, it would require quite > > a bit more work to setup. > > > I would like mini-projects, but not a whole repository. If we can make > this platform running, maybe it can replace sf platform. And I think > mozilla community just like what I want. > > http://www.mozdev.org > > And there are some resources: http://www.mozdev.org/resources/ > > I see there is no trac on it. > > If we don't build a platform like that but we can make a index page to > link separated projects or resources together, I think it's good > either. > > I see there is also a rubyforge(http://rubyforge.org/), and it use php. > > I think we could provide a simple flatform(maybe just link index > page), and if this platform is useful, we can improve it later. > > -- > I like python! > My Blog: http://www.donews.net/limodou > My Django Site: http://www.djangocn.org > NewEdit Maillist: http://groups.google.com/group/NewEdit > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
Hello, I have the feeling that this is more or less already existing. It is called "google code" - http://code.google.com/hosting/search?q=label:django It is taking 2 min to create a new projet. the only thing missing there is a "meta" wiki where the owner of each project can publish information and documentation. This meta wiki can be organized per sections. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
On 8/23/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hello, > > I have the feeling that this is more or less already existing. It is > called "google code" > - http://code.google.com/hosting/search?q=label:django > It is taking 2 min to create a new projet. the only thing missing there > is a "meta" wiki where the owner of each project can publish > information and documentation. This meta wiki can be organized per > sections. > I think if this functionality built on django official site is the better, because every djangor can easy find it. I think the first stage could be the index site supplied by django site, and the exact projects could be found everywhere. And the second stage could be hosting the most django relative projects in django repository site. -- I like python! My Blog: http://www.donews.net/limodou UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad UliPad Maillist: http://groups.google.com/group/ulipad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
I agree with you what absolutely need to be included to the dajngo web site is at least a pointer to the code repository. It would also be nice if djangoproject could host the project documentation. However I think that it would be great to have a sandbox for each project where visitor can experiment with the end result. Then people will be able to dig in the code repository to learn from the part they are interested in. I would dream of something that is dynamically building the sandbox from the trunk of the code repository. Ouuups I was again starting to dream :-) sorry for that. In conclusion I am voting +1 for having a known places where people can share the creation done on top of django. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: [Fw]The Python Web Framework
On 8/22/06, James Bennett <[EMAIL PROTECTED]> wrote: > 1. It's easier to "switch out" pooling utilities this way, or to > switch between pooling and not pooling as circumstances dictate. When > your framework tries to do connection pooling for you, it > automatically gets harder and, depending on whether you can turn the > framework's connection-pooling utility off, maybe even gets > impossible. I've experienced the exact opposite. When I can say in a config file that I want 10 connections in a pool, that's a lot easier for me than setting up an external utility. Moreover, it works with whatever DB I happen to have configured my app to use at the time. > 2. Admittedly I don't have a whole lot of experience in the area, but > creating and managing a pool of connections to be passed from thread > to thread just feels like much more hassle and overhead than we really > need, especially since there are external pooling utilities available. It seems to me that it'd be better to discuss this at the technical level first and then worry about implementation afterward. I realize that the django devs are strapped for time, but that doesn't strike me as grounds for making everyone else solve the same problem over and over again. If it's determined that it is something that should be included in the ORM component, then maybe someone else will step up to the plate. -- Kevin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multi-db: Change DatabaseWrappers to no longer be local?
Ivan Sagalaev wrote: > JP wrote: > > Looking back over the multi-db branch today, I realized that it seems > > to be duplicating the thread locality of connections. The connection > > management classes in multi-db django.db manage all connections as > > thread local, and the DatabaseWrapper classes in the backends are all > > subclasses of local. > > > > I may be missing something, but I think the latter locality can be > > safely removed in multi-db. > > I didn't look how exactly multi-db branch manages connection so my > question may be dumb, sorry. If you intend remove the inheritance of > DatabaseWrapper from locals does it mean that when using single DB > DatabaseWrappers will be shared between threads? Not a dumb question at all. I'll try to explain better by contrasting how multi-db handles connections with how connections are kept thread local in trunk. In trunk, django.db.connection is a DatabaseWrapper instance from some backend. DatabaseWrappers all subclass local, so their attributes are thread local, including the self.connection attribute that is the actual db connection. When you try to get a cursor for the first time in a thread, a connection is made based on the current settings and stored in the local attribute. In multi-db, all connections (including the default that you can access as django.db.connection) are managed through a LazyConnectionManager instance, which keeps a thread-local map of connection name to DatabaseWrapper, and is generally accessed through django.db.connections, like: from django.db import connections, _default, connection foo = connections['foo'] connection is connections[_default] # True When a connection is first accessed in a thread, the connection is established based on the appropriate settings (either defaults or a named connection in OTHER_DATABASES) and a DatabaseWrapper is cached in thread local storage. django.db.connection is a lazy proxy that looks up connections[_default] when accessed for the first time in a thread, and caches the result of that call in another local (for efficiency, otherwise we'd be executing a lambda: every time we touched the connection, which would be bad). So each individual connection instance doesn't need to be a local anymore, because it can only be accessed by a lookup into a local, no matter how you get at it. > > DatabaseWrappers don't have to be local > > because each instance can only be accessed in a particular thread > > anyway. > > I don't exactly understand this bit also. Does it mean that each thread > gets its own instance or that threads can access some (shared) instance? Each thread gets its own DatabaseWrapper instance, rather than one DatabaseWrapper (with local attributes) being shared among all threads. Does that make things more clear? JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multi-db: Change DatabaseWrappers to no longer be local?
JP wrote: > Not a dumb question at all. I'll try to explain better by contrasting > how multi-db handles connections with how connections are kept thread > local in trunk. BTW, I happen to know how it works now since I was among those who was trying to solve threading issues before Eugene Lazutkin's universal patch with DatabaseWrapper inherited from local(). I'm asking because I'm worried if something new could break something working :-) > In multi-db, all connections (including the default that you can access > as django.db.connection) are managed through a LazyConnectionManager > instance, This explains it all, thank you! I now actually found this code in db/backends/__init__.py and from the look of it I agree that inheriting DatabaseWrapper from local() is no longer needed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
Kevin Menard wrote: > I've experienced the exact opposite. When I can say in a config file > that I want 10 connections in a pool, that's a lot easier for me than > setting up an external utility. In my experience such simple behavior is rarely needed. When you actually need a pool it means that your app become pretty large so it requires not only static pool but also other settings like minimum spare connections, maximum spare connections, keep-alive timeouts etc... So this becomes a complex matter in itself and I'd rather Django not to reinvent this. For me this is very similar to the recommendation to use memcached as a cache backend instead of mimicking its rich functionality inside Django. > Moreover, it works with whatever DB I > happen to have configured my app to use at the time. You can use db agnostic pools like SQL Relay. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multi-db: Change DatabaseWrappers to no longer be local?
Ivan Sagalaev wrote: > JP wrote: > > Not a dumb question at all. I'll try to explain better by contrasting > > how multi-db handles connections with how connections are kept thread > > local in trunk. > > BTW, I happen to know how it works now since I was among those who was > trying to solve threading issues before Eugene Lazutkin's universal > patch with DatabaseWrapper inherited from local(). Ah! Sorry, I didn't know the history. I'm sort of new in town. :) > I'm asking because I'm worried if something new could break something > working :-) Me too! > This explains it all, thank you! I now actually found this code in > db/backends/__init__.py and from the look of it I agree that inheriting > DatabaseWrapper from local() is no longer needed. Good. So that's one vote for checking in the change to the branch. Anyone else have any thoughts/objections/questions/whatever? Thanks! JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
I18N+Database Problem
Hello ! First I want to say I'm sorry if I have a poor English, it's not my first language. My problem is that : I start learning I18n with Django but i don't understand how to create langage file (type .po) with the content of the database (like CharField). I wonder if it's possible to do it because database contents are very dynamic and it's seem to me that i18n is very static... If you have solutions for me... Thanks a lot :-) PS:Si il y a des français répondez moi en français cela sera plus simple pour tout le monde ^^ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
I've added the code.google link on the wiki :) In general people will host their projects at google, sourceforge and other sites like these. The basic thing what djangoproject.com should have is a project catalog where all django based projects can be added, listed, searched etc. Second thing - to get more developers use and contribute to django they need to have a django supporting hosting. Developer that makes Open Source software wont be interested in paying for such hosting (and they aren't cheap). They would rather use free alternatives like mentioned sites and for "home sites" - free or very cheap PHP hosting :) I run few FOSS sites and I have free hosting on a commercial LAMP hosting site. I've mailed nearly all hosting companies from the Django Friendly host list and non of them agreed to host my sites for 0$ (in exchange for various help ;)Actually I've got only 3 responses, one of them: bluehost.com "Looking at django website I'm seeing that they do not reccomend running it in cgi mode which would be required on our servers because we do not have mod_python installed nor will we install it due to security issues." Is a "we do not officially support django" a friendly hosting? Now my plan to move my sited to Django is pointless and I'll have to hack dokuwiki and punBB -_- Stats: "Free Django Hosting" 716,000 hits, nr 1. zettai.net didn't responded to me yet (from a week now) "free rails hosting" 6,620,000 hits :) "free php hosting" 139,000,000 hits --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
> In my experience such simple behavior is rarely needed. When you > actually need a pool it means that your app become pretty large so it > requires not only static pool but also other settings like minimum spare > connections, maximum spare connections, keep-alive timeouts etc... So > this becomes a complex matter in itself and I'd rather Django not to > reinvent this. What about cases where running an external connection pooler is not an option, such as shared hosting environments? > For me this is very similar to the recommendation to use memcached as a > cache backend instead of mimicking its rich functionality inside Django. But django still implements file/database/memory caching that does not require memcached. Recommending a particular setup as "best practice" is fine and good, but there should be alternatives for those who can't use or don't need the "recommended" setup. Ideally, it seems django should offer simple connection pooling with 2 options: number of connections and an on/off switch. That would satisfy the needs of some/most, and for those that need something more robust, look into an external pooler. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
Dan Watson wrote: > Ideally, it seems django should offer simple connection pooling with 2 > options: number of connections and an on/off switch. That would satisfy > the needs of some/most, and for those that need something more robust, > look into an external pooler. In your words this looks useful (to me). However I don't see how Django can control the number of connections since on shared hosting you typically have preforking Apache and different Django process can't talk to each other. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Fw]The Python Web Framework
Dan Watson wrote: > Ideally, it seems django should offer simple connection pooling with 2 > options: number of connections and an on/off switch. That would satisfy > the needs of some/most, and for those that need something more robust, > look into an external pooler. Thinking this over a bit more, I think the best solution may be to just provide a hook in core that pool-wanters can use to install pooled connection management. Conveniently :), in the multi-db branch, connections are managed through a connection manager, so there's the hook for those who want to use pooling. The default manager creates one connection per thread, but making one that uses a robust pooling mechanism would be as simple as: 1. stealing sqlalchemy's pool code (MIT licensed) 2. plugging it into a class that acts like django.db.LazyConnectionManager but checks out connections from a pool; the tough part will be hooking up connection.close() to release the connection back into the pool 3. from django import db; db.connections = YourPoolingClass() So in multi-db at least it's doable without too much hackery, and you can plug in whatever kind of pooling you need. JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
db_index not creating indexes with syncdb
I've got the following: class Page(models.Model): name = models.CharField(maxlength=64, db_index=True, unique=True) description = models.TextField(blank=True) class Text(models.Model): page = models.ForeignKey(Page, db_index=True, edit_inline=models.STACKED) content = models.TextField(core=True) When I run "./manage.py syncdb" it creates the tables and everything works ok, but if I look in MySQL at the table description, the index isn't listed: mysql> desc page_text; +--+--+--+-+-++ | Field| Type | Null | Key | Default | Extra | +--+--+--+-+-++ | id | int(11) | | PRI | NULL| auto_increment | | page_id | int(11) | | | 0 || | content | longtext | | | || But if I view the "./manage sqlall page" it lists the CREATE INDEX statements... CREATE TABLE `page_text` ( `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, `page_id` integer NOT NULL, `content` longtext NOT NULL, ); ALTER TABLE `page_text` ADD CONSTRAINT page_id_refs_id_7038ecc2 FOREIGN KEY (`page_id`) REFERENCES `page_page` (`id`); CREATE INDEX page_text_page_id ON `page_text` (`page_id`); And if I copy and paste those statements it works ok too. But I'd expect this to happen via syncdb. There is a bug so I didn't create a new one but it mentions sqlreset even though this bug exists for syncdb... http://code.djangoproject.com/ticket/1828 Are there different places the calls are made for syncdb vs. sqlall? I can dig into the code to see what the differences might be. Thanks, Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: Optgroup integration with FilePathField and SelectField
I'd like to integrate the optgroup tag
(http://www.w3schools.com/tags/tag_optgroup.asp) into the FilePathField
(which would in code would lead to this being tacked onto the
SelectField object) and want to get people's thoughts before writing
the code.
My thought would be that:
NAME_CHOICES = (
('Male', (("John", "John"), ("Steve", "Steve"))),
('Female', ("Jane", "Jane")),
('?', "Unknown")
)
would produce:
John
Steve
Jane
Unknown
The main reason this functionality is desired is for the FilePathField.
When recursive = True, it would be nice if the directories would be
displayed inside a optgroup-enhanced select tag. If the directories go
more then 2 directories deep, I assume it would be best to revert back
to the regular method, displaying all the files in a single
non-optgroup enabled list, since it appears that only IE 5 for Mac
supports multi-nested-optgroups
(http://www.netmechanic.com/news/vol4/html_no20.htm).
Any comments/thoughts/enhancements? If you don't like this, is there
another way of doing this without mucking up the predefined objects?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
Resurrecting an old thread...
Let's make this happen!
Joseph (in the e-mail below) has spelled out a pretty decent plan for
the new manipulator scheme. I see that we've got another proposal in
Trac by Brant Harris -- http://code.djangoproject.com/ticket/2586.
Let's get something decided and implemented for Django's next version;
this will be one of the last big(ish) changes before 1.0.
Models already have a validate() method, but it's undocumented and not
all validation (for all field types) is implemented.
Put succinctly, we're looking to replace the automatic AddManipulators
and ChangeManipulators that Django creates for each model. We're
looking for something more natural, more flexible and more sexy.
Definitely more sexy.
How To Be Sexy, Rule 1: The word "manipulator" has really got to go.
Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
plan in Trac?
Adrian
On 3/8/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> The short version of this is really, forms and manipulators merge and
> get more powerful, models grow validation. This is an attempt to
> clarify and add to Adrian's previous proposal. I hope it takes care of
> people's concerns. Here are some details:
>
> Forms and FormFields are intended to be used for web applications
> only. Models do validation, so using forms isn't necessary when
> manipulating data directly in python. Also, I think something similar
> to this would allow for recursive forms (edit_inline behavior), but I
> haven't worked out all the details.
>
> Models would grow a validate method and validate=True is added as an
> argument to Model's save methods. Models would not do any type
> coercion. (I guess they could, but I think most type coercion should
> happen in the form fields, not the model fields.)
>
> I'm ignoring a bunch of metaclass magic that needs to go on here, but
> I hope the intentions are clear. Bring on the pseudocode...
>
>
> class Form(object):
> def __init__(self, request, prefix=''):
> self.request = request
> # prefix corresponds to a prefix to http variable names. The prefix
> # should be used to strip off the first part of the var names.
> # Hopefully this will allow for recursively defined forms... in other
> # words, edit_inline is available outside of the admin system.
> self.prefix = prefix
> # this would actually be more complicated... use prefix to get a dict
> # of strings for the form fields to coerce.
> self.data = request.POST.copy()
>
> def _get_model_obj(self):
> """
> return the cached model object, or init/cache/return one.
> """
>
> model = property(_get_model_obj)
>
> def set_defaults(self):
> """
> Call get_default() (hopefully passing in self.request) on each
> FormField, and set the appropriate attributes on self.model.
> """
>
> def validate(self):
> """
> Basically just return self.model.validate(). Call validate for child
> forms as well.
> """
>
> def save(self, validate=True):
> """
> Basically just call self.model.save(validate=validate) Call save for
> child forms as well.
> """
>
> def html(self):
> """
> This is really just convenience for people who are too lazy to write
> real templates. Returns a very generic form redered as html. It
> should probably have enough css hooks to make it workable though. It
> is meant to be called in a template like {{ form.html }}
> """
>
> class ArticleAddForm(Form):
> # author will not be editable or displayed
> exclude_fields = ('author',)
> extend_fields = (
> formfields.EmailField(field_name="from", is_required=True),
> )
>
> class ArticleChangeForm(Form):
> # author will be displayed, but not editable
> readonly_fields = ('author',)
>
> class Article(models.Models):
> name = models.CharField(maxlength=100)
> body = models.TextField()
> author = models.AuthorField()
>
> class Meta:
> # this gets used in generic create views
> add_form = ArticleAddForm
>
> class Admin:
> # this gets used in the admin system
> change_form = ArticleChangeForm
>
>
> # Usage:
> def myview(request):
> add_form = Article.AddForm(request)
> errors = add_form.validate()
> if not errors:
> add_form.save(validate=False)
> return HttpResponseRedirect('the_next_page')
> ctx = RequestContext({'form': add_form})
> return render_to_response('template', ctx)
>
>
> I hope something like this will come out of Adrian's validation aware
> model proposal. This would solve those issues, and add a ton of
> flexibility to Django. There are many details that need to be pinned
> down, but I think something like this should be workable.
>
> Also, there are things that I've probably overlooked. What are they?
>
> Jose
Re: Re: Validation Aware Models and django.forms on steroids
On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Thoughts/comments/suggestions on Joseph's plan below, and on Brant's > plan in Trac? I think Brant's rocking the sexiness; the concept of validation behaving as a try/except block feels nice to me. And bidding good-bye to 'if errors', FormWrapper and friends will be a huge win. The exact details could use a little fine-tuning, though; a couple things in particular jump out at me: 1. I'm not sure I like the idea of manipulators having a 'process' method which does everything; it would feel more natural to just try 'manipulator.save()', have that save if all is well, and catch any validation errors. 2. Since we're already striving hard to get rid of 'get_absolute_url' I'm not sure how I feel about introducing a 'get_update_url'. 3. Doing 'manipulator.process(request)' is probably unacceptable, since there are tons of common use cases where you'll want to fiddle with the soon-to-be-validated data before you let the manipulator get involved. I can live with 'new_data' in this case. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: db_index not creating indexes with syncdb
try ./manage.py install, it executes sqlall Corey On Aug 23, 2006, at 2:42 PM, [EMAIL PROTECTED] wrote: > > I've got the following: > > class Page(models.Model): > name = models.CharField(maxlength=64, db_index=True, > unique=True) > description = models.TextField(blank=True) > > class Text(models.Model): > page = models.ForeignKey(Page, db_index=True, > edit_inline=models.STACKED) > content = models.TextField(core=True) > > When I run "./manage.py syncdb" it creates the tables and everything > works ok, but if I look in MySQL at the table description, the index > isn't listed: > > mysql> desc page_text; > +--+--+--+-+- > ++ > | Field| Type | Null | Key | Default | > Extra | > +--+--+--+-+- > ++ > | id | int(11) | | PRI | NULL| > auto_increment | > | page_id | int(11) | | | 0 > || > | content | longtext | | | > || > > But if I view the "./manage sqlall page" it lists the CREATE INDEX > statements... > > CREATE TABLE `page_text` ( > `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY, > `page_id` integer NOT NULL, > `content` longtext NOT NULL, > ); > ALTER TABLE `page_text` ADD CONSTRAINT page_id_refs_id_7038ecc2 > FOREIGN > KEY (`page_id`) REFERENCES `page_page` (`id`); > CREATE INDEX page_text_page_id ON `page_text` (`page_id`); > > And if I copy and paste those statements it works ok too. But I'd > expect this to happen via syncdb. > > There is a bug so I didn't create a new one but it mentions sqlreset > even though this bug exists for syncdb... > http://code.djangoproject.com/ticket/1828 > > Are there different places the calls are made for syncdb vs. > sqlall? I > can dig into the code to see what the differences might be. > > Thanks, > Rob > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
limodou wrote: > I think if this functionality built on django official site is the > better, because every djangor can easy find it. I think the first > stage could be the index site supplied by django site, and the exact > projects could be found everywhere. And the second stage could be > hosting the most django relative projects in django repository site. As for a first stage, the djangoproject wiki would work. For example, a contributed middleware page already exists: http://code.djangoproject.com/wiki/ContributedMiddleware --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
On 8/24/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > > limodou wrote: > > I think if this functionality built on django official site is the > > better, because every djangor can easy find it. I think the first > > stage could be the index site supplied by django site, and the exact > > projects could be found everywhere. And the second stage could be > > hosting the most django relative projects in django repository site. > > As for a first stage, the djangoproject wiki would work. For example, > a contributed middleware page already exists: > http://code.djangoproject.com/wiki/ContributedMiddleware > I don't think wiki suit for this. And I assume that the index site should look like a portal, and it should be visible in django official site. -- I like python! My Blog: http://www.donews.net/limodou UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad UliPad Maillist: http://groups.google.com/group/ulipad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
so Limodou. what's the next step. have you got a prototype of it ? or a idea on how it will work? I've got a old linux box you can use to host it until it gets popular. I'm more for just storing the meta-data of the project, and let the owners of the project host it on their own (or googles or whoevers) SVN servers. regards ian On 24/08/2006, at 1:40 PM, limodou wrote: > > On 8/24/06, Gary Wilson <[EMAIL PROTECTED]> wrote: >> >> limodou wrote: >>> I think if this functionality built on django official site is the >>> better, because every djangor can easy find it. I think the first >>> stage could be the index site supplied by django site, and the exact >>> projects could be found everywhere. And the second stage could be >>> hosting the most django relative projects in django repository site. >> >> As for a first stage, the djangoproject wiki would work. For >> example, >> a contributed middleware page already exists: >> http://code.djangoproject.com/wiki/ContributedMiddleware >> > I don't think wiki suit for this. And I assume that the index site > should look like a portal, and it should be visible in django official > site. > > -- > I like python! > My Blog: http://www.donews.net/limodou > UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad > UliPad Maillist: http://groups.google.com/group/ulipad > > > -- Ian Holsman [EMAIL PROTECTED] http://personalinjuryfocus.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > so Limodou. > > what's the next step. > have you got a prototype of it ? or a idea on how it will work? > I've got a old linux box you can use to host it until it gets popular. No, I haven't a plan about it, just some ideas. If someone make it a project, I would like to join it. But I have not so much time now, and I'm improving my UliPad project now. > > I'm more for just storing the meta-data of the project, and let the > owners of the project host it on their own (or googles or whoevers) > SVN servers. > What you want exactly the first stage of my thought, but if this thing can be support be django team is the best. If you want to implement such site? > regards > ian > -- I like python! My Blog: http://www.donews.net/limodou UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad UliPad Maillist: http://groups.google.com/group/ulipad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
On 24/08/2006, at 2:00 PM, limodou wrote: > > On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote: >> >> so Limodou. >> >> what's the next step. >> have you got a prototype of it ? or a idea on how it will work? >> I've got a old linux box you can use to host it until it gets >> popular. > > No, I haven't a plan about it, just some ideas. If someone make it a > project, I would like to join it. But I have not so much time now, and > I'm improving my UliPad project now. >> >> I'm more for just storing the meta-data of the project, and let the >> owners of the project host it on their own (or googles or whoevers) >> SVN servers. >> > What you want exactly the first stage of my thought, but if this thing > can be support be django team is the best. If you want to implement > such site? luckily? for me I have a bit of time on my hands tomorrow and possibly monday. i could get a start on something 'forgish' which could then be used to critique/improve on. > >> regards >> ian >> > > > -- > I like python! > My Blog: http://www.donews.net/limodou > UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad > UliPad Maillist: http://groups.google.com/group/ulipad > -- Ian Holsman [EMAIL PROTECTED] http://personalinjuryfocus.com/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: Django Apps & Project Repository (again)
On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > > > On 24/08/2006, at 2:00 PM, limodou wrote: > > > > > On 8/24/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > >> > >> so Limodou. > >> > >> what's the next step. > >> have you got a prototype of it ? or a idea on how it will work? > >> I've got a old linux box you can use to host it until it gets > >> popular. > > > > No, I haven't a plan about it, just some ideas. If someone make it a > > project, I would like to join it. But I have not so much time now, and > > I'm improving my UliPad project now. > >> > >> I'm more for just storing the meta-data of the project, and let the > >> owners of the project host it on their own (or googles or whoevers) > >> SVN servers. > >> > > What you want exactly the first stage of my thought, but if this thing > > can be support be django team is the best. If you want to implement > > such site? > > luckily? for me I have a bit of time on my hands tomorrow and > possibly monday. > i could get a start on something 'forgish' which could then be used > to critique/improve on. > Wonderful, I think this will be a great work! -- I like python! My Blog: http://www.donews.net/limodou UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad UliPad Maillist: http://groups.google.com/group/ulipad --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Validation Aware Models and django.forms on steroids
Finally! I've been waiting :) On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > How To Be Sexy, Rule 1: The word "manipulator" has really got to go. > > Thoughts/comments/suggestions on Joseph's plan below, and on Brant's > plan in Trac? > I know you want to get rid of the concept of "Manipulator". So two things: 1. I will think very hard of alternate ways of doing this. 2. Currently I think the idea of the "Manipulator" is really quite great. It allows you to define, in a simple way, a Form process. But also, the whole idea of the manipulator means that the "manipulation" of an object is in the "model" space, essentially, and not in the "view" space. Maybe it's a philosophic question, but I see it best defined in the "model" space because then it provides a modular process for views to leverage. Maybe a constructive thing would be to decide what we DON'T like in the current Manipulators system? Personally most of the problems I see, have been sorted out in my proposal. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Validation Aware Models and django.forms on steroids
On 8/23/06, James Bennett <[EMAIL PROTECTED]> wrote: > 1. I'm not sure I like the idea of manipulators having a 'process' > method which does everything; it would feel more natural to just try > 'manipulator.save()', have that save if all is well, and catch any > validation errors. The problem is that to make it usefull to the user (read: api-user / developer), you have to put the model save in a try / except block so that if there is a validation error, it can raise the form. Otherwise, the user will have to provide their own try / except block. > 2. Since we're already striving hard to get rid of 'get_absolute_url' > I'm not sure how I feel about introducing a 'get_update_url'. I totally agree. Maybe get_url() and get_edit_url()? I think most objects should have a .url property. And come to think of it, this might be an entry for some sort of routes implimentation, that's not routes (man I hate the routes syntax). > 3. Doing 'manipulator.process(request)' is probably unacceptable, > since there are tons of common use cases where you'll want to fiddle > with the soon-to-be-validated data before you let the manipulator get > involved. I can live with 'new_data' in this case. Yeah, you know I agree. In an earlier rendition I was doing manipulator.process(request.POST), which actually makes a lot more sense to me. But that disallows easy access to the request.user, which makes it harder to make a manipulator that, for instance, automatically updates an author field with the current user. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Re: Validation Aware Models and django.forms on steroids
On 8/23/06, Brantley Harris <[EMAIL PROTECTED]> wrote: > The problem is that to make it usefull to the user (read: api-user / > developer), you have to put the model save in a try / except block so > that if there is a validation error, it can raise the form. > Otherwise, the user will have to provide their own try / except block. If I'm reading the example on the wiki correctly, you'd already need to do this in your view -- the difference is whether the try/except wraps around 'manipulator.process' or 'manipulator.save', and though it's mainly semantics, I think the latter is preferable. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Re: Re: Validation Aware Models and django.forms on steroids
On 8/24/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 8/23/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> > The problem is that to make it usefull to the user (read: api-user /
> > developer), you have to put the model save in a try / except block so
> > that if there is a validation error, it can raise the form.
> > Otherwise, the user will have to provide their own try / except block.
>
> If I'm reading the example on the wiki correctly, you'd already need
> to do this in your view -- the difference is whether the try/except
> wraps around 'manipulator.process' or 'manipulator.save', and though
> it's mainly semantics, I think the latter is preferable.
No, watch for the difference between a ValidationError being raised
and a Form exception being raised. In the ValidationError case, it
must be saved and returned with the other validation errors in the
given step (1. conversion; 2. form validation; 3. model validation),
and then finally a Form exception must be raised.
Check out the ._save() function in the Manipulator. It wraps the user
provided .save(), and catches the ValidationError and raises a Form.
Come to think about it, ValidationError really should be
ValidationErrors, with an s. If at all possible we should get as many
errors out as we can to give to the form-user. That's why I pick out
those three steps above; no later step can go forward, or even check
for errors, before the previous steps are complete.
I did play with:
m = Manipulator(request.POST)
m.save()
That has some merit, I think. But again, the user would have to
provide a try / except block. Something like this:
try:
m = Manipulator(request.POST)
m.save()
except ValidationErrors, errors:
render_to_response('polls/create.html', {'form': m.get_form(errors)})
Not very pretty...
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Re: Re: Re: Validation Aware Models and django.forms on steroids
On 8/24/06, Brantley Harris <[EMAIL PROTECTED]> wrote:
> No, watch for the difference between a ValidationError being raised
> and a Form exception being raised. In the ValidationError case, it
> must be saved and returned with the other validation errors in the
> given step (1. conversion; 2. form validation; 3. model validation),
> and then finally a Form exception must be raised.
Huh?
Here's one of the example views ripped straight out of the wiki page:
def create_poll(request):
try:
m = Poll.CreateManipulator()
poll = m.process(request)
return HttpResponseRedirect('/polls/%d/' % poll.id)
except Form, form:
return render_to_response('polls/create.html', {'form': form})
Where is this bit about catching "ValidationError" coming from?
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
