Re: database connection user - newbie question
> well. Sure, someone mentioned the possability of some money for > development, but that doesn't cover the long term maintianence, which is > what the core devs are looking for. If someone is offering to pay for development of a feature that will enable them to use the framework for their software, do you really think they're going to neglect the maintenance of this feature in the long run? On May 11, 11:47 am, Waylan Limberg <[EMAIL PROTECTED]> wrote: > On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote: > > > I think what you're overlooking is that in some cases the issue of > > whether its the "best solution" is irrelevant. If the database is > > already in production or the policies are already set or controlled by > > an external entity, then debating the merits of the single DB, single > > connection philosophy is pointless. > > > Since we're all into historical anecdotes :) lets take a look at the > > COM/CORBA school of thought. > > What you seem to be missing is that the core devs are not questioning > that. Rather, they are all in situations were they don't need multi-db > support. Some here seem to have taken their explaination to mean they > don't want mutli-db support. But that it *not* what they said. In fact, > when the multi-db branch started (over a year ago) they seemed eager to > see something they could include into trunk. Unfortunelty, that > something has not materialized as noone (that needs that feauture and > can therefore adequeatly test it etc.) has stepped up to the plate to > finish development and comitt to long term maintanence. Remember, the > core devs are all doing this in their free time not-for-pay. Therefore, > they are are scratching their own itch. Your welcome to scratch yours as > well. Sure, someone mentioned the possability of some money for > development, but that doesn't cover the long term maintianence, which is > what the core devs are looking for. > > This same debate has been played over and over for all of the stagnet > branches and, quite frankly, I'm getting tired of the pointlesness of it > all. No wonder Adrian and Jacob never (rarely?) respond to these kinds > of messages anymore. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On Thu, 2007-05-10 at 22:58 +, [EMAIL PROTECTED] wrote: > > I think what you're overlooking is that in some cases the issue of > whether its the "best solution" is irrelevant. If the database is > already in production or the policies are already set or controlled by > an external entity, then debating the merits of the single DB, single > connection philosophy is pointless. > > Since we're all into historical anecdotes :) lets take a look at the > COM/CORBA school of thought. What you seem to be missing is that the core devs are not questioning that. Rather, they are all in situations were they don't need multi-db support. Some here seem to have taken their explaination to mean they don't want mutli-db support. But that it *not* what they said. In fact, when the multi-db branch started (over a year ago) they seemed eager to see something they could include into trunk. Unfortunelty, that something has not materialized as noone (that needs that feauture and can therefore adequeatly test it etc.) has stepped up to the plate to finish development and comitt to long term maintanence. Remember, the core devs are all doing this in their free time not-for-pay. Therefore, they are are scratching their own itch. Your welcome to scratch yours as well. Sure, someone mentioned the possability of some money for development, but that doesn't cover the long term maintianence, which is what the core devs are looking for. This same debate has been played over and over for all of the stagnet branches and, quite frankly, I'm getting tired of the pointlesness of it all. No wonder Adrian and Jacob never (rarely?) respond to these kinds of messages anymore. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Fwd: << Want To Be An Astronaut >>
its a dream profession , Thanks *if you want to be an Astronaut of NASA please read this guaid* http://information.100stuff.com/want-to-be-astronaut/ Thanks Rania --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Fwd: <<< Top 10 Uk Universities >>>
please tell me best computer science university in uk. Hello Friends, *Here are Top 10 UK Universities admission open in some universities and some universities give you visa assistance. http://students.awepedia.info/top-10-uk-universities/ if you needs more information about universities please reply me and if you have any use full information about admission in abrade universities please share us. Thanks Sania Desai * --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Type coercion in Django
On Thu, 2007-05-10 at 08:14 -0700, Gulopine wrote: > I think this discussion could use a bit of revival, as it seems > obvious to me that there are groups that could benefit from some sort > of field-level coercion. In addition to my DurationField and the > various possibilities available with GeoDjango, there are other things > that would be useful in various contexts. > > Consider a ColorField that could store its value as an INTEGER for > efficiency, but allows Python to access it as a 3-tuple of (red, > green, blue). This could be done for both assignment and retrieval, > with the field dealing with everything in between using to_python and > get_db_prep_save. In fact, something like this is almost possible > already, with get_db_prep_save handling transmission into the > database, and get_db_prep_lookup dealing with lookup types. In theory > (with a good bit of work, I expect) it should be possible to search on > such a color field with something like > Model.objects.filter(color__red_gt=200) to get objects with a lot of > red in their color. That's probably a bad example given the SQL that > would be necessary to look up on part of an INTEGER while ignoring the > rest of it, but it shows what kind of out-of-the-box thinking would be > possible if the one missing component (to_python) were in place to > handle coercion into a proper Python type. > > Another example would be a variant of XMLField that gives its contents > to Python as a minidom.Document object. Something your explanation hasn't addressed so far is actually creating the right Python types in the models and this surprises me a little. If you're doing all this thinking about how to map from database fields to special types, surely the Model.__init__ changes need to come into the picture so that accessing MyModel.foo returns the right Python type, too. Luckily, we've thought about this before. Most of the core changes needed to add extra field types, particularly those that subclass existing database types, is essentially. It's about three lines of code (there was a patch published on this list or django-users last year, from memory). You basically just have to change the place in Model.__init__() that assigns the database-retrieved value to a Python instance attribute with a call to an init()-like method that acts like you are describing for to_python() -- if such a function exists. Normally I would point you to the exact thread, but I can't seem to search it out. In any case, the changes are really trivial. I think there was some reason you could just use the __init__ method on the class as the "converter to Python instance", but I may be misremembering The only vaguely tricky part we didn't solve last time was getting this to work with serialisation in a reasonably transparent fashion. The idea was to push pretty much all the work off to the sub-classes. So the sub-classes special method (be it called to_python() or whatever) would be given the database value and return an instance that proxies for that value. In short, I think your assessment of the situation as far as creating new data types that map to database fields is broadly correct. I haven't looked at the patch you mentioned at the start of this thread in detail and won't have time to do so for quite a while yet. I am completely buried in Django work in my spare moments and have slightly less than zero free time. At a glance, I think the patch needs some thinking about whether it's in the right place, since it's clearly doing a bit more work each time than the current implementation and function calls and pop() calls are not free. Not saying it's wrong, per se, just that it's not a no-brainer, either. Regards, Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: When will updatedb be completed?
On Fri, 2007-05-11 at 08:11 +0800, Russell Keith-Magee wrote: > On 5/11/07, James Bennett <[EMAIL PROTECTED]> wrote: > > > > On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote: > > > Do any of you guys when the django-admin.py updatedb command will be > > > completed? updatedb is basically all django is missing for me and many > > > developers at the company I work for to abandon CakePHP and move to > > > django. > > > > As far as I know, none of the core development team are actively > > working on any form of automated schema evolution. There is a branch, > > but it is the responsibility of a volunteer who was writing the code; > > if you're interested in seeing that code completed, the best thing to > > do is contact the person who was working on it and see about > > collaborating to finish the work. > > There's actually two branches (schema-evolution and > schema-evolution-ng); in addition to those, I can recall at least 2 > occasions in the last six months where someone has offered to work on > schema-evolution.. > > Unfortunately, schema evolution seems to be a black hole for > contributors. People offer to work on schema evolution, and they are > never heard from again... :-) This effort http://www.aswmc.com/dbmigration/ is actually a pretty good (and recent) piece of work. It's not completely automatic (since that's impossible), but it's reasonably easy to use. Regards, Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Two field-related suggestions for newforms.models
On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 5/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> >
> > I've got a working implementation and some proof-of-concept tests;
> > would you like me to clean this up and push it into the trunk, or do
> > you want to handle it yourself?
>
> If you want to add it to the trunk that would be awesome. I can just
> merge the changes into the newforms-admin branch. It's overdue for a
> merge anyhow.
Will do.
> > > +1 for optionally doing this for ManyToManyField at least. Would the
> > > reverse ForeignKey interface be similar to edit_inline? I think once I
> > > finish the formset-model integration code, that should be pretty
> > > simple to pull off.
> >
> > I would have thought reverse foreign key would have be more like m2m
> > than edit inline. The reverse case is more like 'which of these
> > objects are have FK relations pointing to this one?', so a 'select
> > multiple' widget would be appropriate.
>
> Ahh. I'll echo Malcolm's +0 on that then. I haven't found a need for
> it, but it seems like I'd find a use for it if it were there.
Ideally, IMHO, it should be possible to do both. Its just a matter of
how to specify edit-inline preferences on a form_for_model, etc. I
haven't thought about this too hard, but something like:
form_for_model(
MyModel,
fields=('field1', 'field2', 'fkfield'),
reverse_fields=('revfield1, 'revfkfield'),
inline={
'fkfield': Tabular,
'rev_fkfield': Stacked
})
would allow you to:
- default to something simple
- easily introduce inline representations
- easily pull definitions from a ModelAdmin type class to put into a
form_for_model used by the admin view.
Yours,
Russ Magee %-)
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Two field-related suggestions for newforms.models
On 5/10/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > > > I realize that you can subclass the form class returned by the > > > form_for_ methods and delete the fields you don't want, but 'form from > > > field subset' seems like a fairly common use case that can be very > > > easily accommodated. > > > > +1. I'm planning on adding a similar argument to edit-inline. Writing > > a one-off formfield_callback seems like an awful lot of work for such > > a common task. I'm sure the same thing could be implemented as a > > wrapper around the form_for_ functions using formfield_callback, but I > > don't see any particular reason to do it that way as long as the > > behavior of the 'fields' argument was documented as Malcolm said. > > I've got a working implementation and some proof-of-concept tests; > would you like me to clean this up and push it into the trunk, or do > you want to handle it yourself? If you want to add it to the trunk that would be awesome. I can just merge the changes into the newforms-admin branch. It's overdue for a merge anyhow. > > > 2) I realize that there are historical (i.e., > > > manipulator/pre-magic-removal related) reasons why reverse ForeignKey > > > and M2M relations are not contained on forms, but is there any reason > > > that newforms should continue the tradition? > > > > > +1 for optionally doing this for ManyToManyField at least. Would the > > reverse ForeignKey interface be similar to edit_inline? I think once I > > finish the formset-model integration code, that should be pretty > > simple to pull off. > > I would have thought reverse foreign key would have be more like m2m > than edit inline. The reverse case is more like 'which of these > objects are have FK relations pointing to this one?', so a 'select > multiple' widget would be appropriate. Ahh. I'll echo Malcolm's +0 on that then. I haven't found a need for it, but it seems like I'd find a use for it if it were there. 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?hl=en -~--~~~~--~~--~--~---
Re: When will updatedb be completed?
On 5/11/07, James Bennett <[EMAIL PROTECTED]> wrote: > > On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote: > > Do any of you guys when the django-admin.py updatedb command will be > > completed? updatedb is basically all django is missing for me and many > > developers at the company I work for to abandon CakePHP and move to > > django. > > As far as I know, none of the core development team are actively > working on any form of automated schema evolution. There is a branch, > but it is the responsibility of a volunteer who was writing the code; > if you're interested in seeing that code completed, the best thing to > do is contact the person who was working on it and see about > collaborating to finish the work. There's actually two branches (schema-evolution and schema-evolution-ng); in addition to those, I can recall at least 2 occasions in the last six months where someone has offered to work on schema-evolution.. Unfortunately, schema evolution seems to be a black hole for contributors. People offer to work on schema evolution, and they are never heard from again... :-) Personally, I'm very keen to see schema evolution done (and done well). I've got a whole lot of other stuff on my plate at the moment, so I wouldn't count on schema evolution emerging from _my_ corner any time soon. However, if some enterprising soul wants to make an effort, I'm happy to help out wherever I can. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: When will updatedb be completed?
Hey James, Do you have this person's contact info so we can coordinate the completion of that function? Thanks, Sebastian On May 10, 2:53 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote: > > > Do any of you guys when the django-admin.py updatedb command will be > > completed? updatedb is basically all django is missing for me and many > > developers at the company I work for to abandon CakePHP and move to > > django. > > As far as I know, none of the core development team are actively > working on any form of automated schema evolution. There is a branch, > but it is the responsibility of a volunteer who was writing the code; > if you're interested in seeing that code completed, the best thing to > do is contact the person who was working on it and see about > collaborating to finish the work. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Two field-related suggestions for newforms.models
On 5/11/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > > I realize that you can subclass the form class returned by the > > form_for_ methods and delete the fields you don't want, but 'form from > > field subset' seems like a fairly common use case that can be very > > easily accommodated. > > +1. I'm planning on adding a similar argument to edit-inline. Writing > a one-off formfield_callback seems like an awful lot of work for such > a common task. I'm sure the same thing could be implemented as a > wrapper around the form_for_ functions using formfield_callback, but I > don't see any particular reason to do it that way as long as the > behavior of the 'fields' argument was documented as Malcolm said. I've got a working implementation and some proof-of-concept tests; would you like me to clean this up and push it into the trunk, or do you want to handle it yourself? > > 2) I realize that there are historical (i.e., > > manipulator/pre-magic-removal related) reasons why reverse ForeignKey > > and M2M relations are not contained on forms, but is there any reason > > that newforms should continue the tradition? > > > +1 for optionally doing this for ManyToManyField at least. Would the > reverse ForeignKey interface be similar to edit_inline? I think once I > finish the formset-model integration code, that should be pretty > simple to pull off. I would have thought reverse foreign key would have be more like m2m than edit inline. The reverse case is more like 'which of these objects are have FK relations pointing to this one?', so a 'select multiple' widget would be appropriate. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 5/10/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > On 5/5/07, Jari Pennanen <[EMAIL PROTECTED]> wrote: > > > > Modularity of edit inline? Any better? > > > > Currently: > > models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...) > > obiviously is a big waste of OO abilities, > > > > instead something like, the OO way: > > models.ForeignKey(Other, edit_inline=models.TabularInline(parameters)) > > were much better. (I know it is defined elsewhere in upcoming > > implementation, but the example I saw did not implement subclassing > > which I think is neccessity to create it customizable, and also the > > parameters is way more clear this way) > > > > One could implement own edit inlines just by subclassing from > > TabularInline/StackedInline, or from where TabularInline subclassed > > itself. Currently I see no easy or sensible way to create own edit > > inlines. > > That's the general idea of what we came up with at PyCon. I'm still > working on the underlying machinery (basically formset_for_model and > formset_for_instances) though. TabularInline/StackedInline (or > whatever they end up being) will be mostly configuration, however, > they are an incredibly small part of the overall implementation and > will be one of the last things I work on. I imagine they will have > some methods to customize them a little via subclassing, but I'm not > going to speculate further until I get there. Oops. Actually let me clarify that a bit. The edit_inline definition will definitely *not* be an argument to ForeignKey, but rather an argument to either AdminSite.register or ModelAdmin (most likely the latter). Passing configuration data into ModelAdmin still hasn't been finalized, so I can't really tell you exactly what it will look like, but the main point is that edit_inline definitions will happen completely *outside* of the model. 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 5/5/07, Jari Pennanen <[EMAIL PROTECTED]> wrote: > > Modularity of edit inline? Any better? > > Currently: > models.ForeignKey(Other, edit_inline=models.TABULAR, parameters...) > obiviously is a big waste of OO abilities, > > instead something like, the OO way: > models.ForeignKey(Other, edit_inline=models.TabularInline(parameters)) > were much better. (I know it is defined elsewhere in upcoming > implementation, but the example I saw did not implement subclassing > which I think is neccessity to create it customizable, and also the > parameters is way more clear this way) > > One could implement own edit inlines just by subclassing from > TabularInline/StackedInline, or from where TabularInline subclassed > itself. Currently I see no easy or sensible way to create own edit > inlines. That's the general idea of what we came up with at PyCon. I'm still working on the underlying machinery (basically formset_for_model and formset_for_instances) though. TabularInline/StackedInline (or whatever they end up being) will be mostly configuration, however, they are an incredibly small part of the overall implementation and will be one of the last things I work on. I imagine they will have some methods to customize them a little via subclassing, but I'm not going to speculate further until I get there. 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?hl=en -~--~~~~--~~--~--~---
Re: Two field-related suggestions for newforms.models
On 4/29/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > 1) Is there room for a 'fields' argument on form_for_instance and > form_for_model - a list of field names that you want included on the > form (defaulting to None, meaning the full list), so that it is simple > to create a form with a subset of a model's full field list? > > I realize that you can subclass the form class returned by the > form_for_ methods and delete the fields you don't want, but 'form from > field subset' seems like a fairly common use case that can be very > easily accommodated. +1. I'm planning on adding a similar argument to edit-inline. Writing a one-off formfield_callback seems like an awful lot of work for such a common task. I'm sure the same thing could be implemented as a wrapper around the form_for_ functions using formfield_callback, but I don't see any particular reason to do it that way as long as the behavior of the 'fields' argument was documented as Malcolm said. > 2) I realize that there are historical (i.e., > manipulator/pre-magic-removal related) reasons why reverse ForeignKey > and M2M relations are not contained on forms, but is there any reason > that newforms should continue the tradition? > > We probably don't want to include reverse fields on forms by default > (if only for backwards compatibility), but providing an optional > argument (say, reverse_fields=(...), containing a list of reverse > descriptor names) on form_for_model and form_for_instance would allow > users to easily include reverse relations on a form. +1 for optionally doing this for ManyToManyField at least. Would the reverse ForeignKey interface be similar to edit_inline? I think once I finish the formset-model integration code, that should be pretty simple to pull off. 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
"While I'm not saying that multiple DB-level users and DB-level access controls are the wrong solution, I would ask up-front what specific real-world problem is being solved by this, and whether it really is the best solution." I think what you're overlooking is that in some cases the issue of whether its the "best solution" is irrelevant. If the database is already in production or the policies are already set or controlled by an external entity, then debating the merits of the single DB, single connection philosophy is pointless. Since we're all into historical anecdotes :) lets take a look at the COM/CORBA school of thought. Coming from a MS background, I'm more familiar with the COM saga personally. There was a time when a lot of people thought COM was the way forward and DCOM (distributed COM) was going to lead the way to distributed object oriented engineering bliss. MS spent a lot of money and resources pursuing this technology and if you look at the internals of many of the Windows bits and pieces, COM is very prevalent even today. In time COM was displaced by the combo of .NET and web services technologies such as SOAP/XML- RPC. That does not however mean that COM-based software magically went away. In fact many companies in the business world that built their software on top of COM are still rolling out new features on top of that same infrastructure. Now we can sit here and pooh-pooh their use of COM all day but the moment we need to interface with their platform all the bitching in the world will not provide a single ounce of problem solving. It simply doesn't change the fact that while something may have been designed and implemented according to state of the art at that moment, in five or ten years the capabilities and techniques available across the landscape of software engineering will render those previous designs useless or antiquated or even silly (as you point out with the password change policy example). And who is to say what is the "best" state of the art solution? One of the beauties of software engineering to me is that for a given requirement many different looking solutions can be adequate. For example, 3 developers are tasked with improving the performance of a web application: -Developer A, who just got back from a LAMP Scaling and Architecture conference, decides to buy another server box and cluster the database across 2 servers. -Developer B, who just got back from a MySQL conference, realizes that they can categorize the data access for the application into distinct categories and then apply different storage engines to the tables that fall into each category. Overall a day or two of work. -Developer C, who is really more of a DBA, relies on their years of experience fine tuning and optimizing DB performance to both move some of the business logic into sprocs and functions where it will execute on top blazingly fast compiled code rather than interpreted Python and also creates a separate read-only logical database that provides an extra 10-15% boost due to the large amount of reference data pulled on many requests. Based on hardware costs, developer salary costs, company policies, project timelines, legal issues, and the many other factors that affect our day-to-day activities, who made the best decision and who made the worst decision? I will state that since each developer chose a path that was comfortable to them given their specific engineering experience, they all made good decisions. The caveat is that they all need to understand what the trade offs of their particular decision meant to the larger and future scope of the application. There are 2 main themes that I've taken away from the recent discussions surrounding these issues. The first is that for the time being the collective developer standpoint is that Django is being positioned (primarily? mostly?) as a framework targeting early stage web application development. The framework is very well suited for this role IMHO. I continue to encourage the development team to gather the many sound and logical arguments that have been presented in favor the of the single DB, single connection (SDB/SC if I may) paradigm and at least put this into a section somewhere on the site and/or book documentation. I think that this is valuable, educational information for users. In particular, for users who are creating new applications it might be beneficial to some to understand the potential negative consequences as you have laid out so that they don't invest time going down the road of planning certain aspects of their design at the database level. In effect you are simply arming people who have decided to invest time in learning the framework with information that will help them get the best use of out the framework in accordance with what the developers intend it to be. That would seem to be a win/win situation. This is not of course to imply that Django is not well suited to scaling up to
Changing django.contrib.auth to make passwords optional
I'm working on a new component for my Django OpenID package which will provide support for associating one or more OpenIDs with a django.contrib.auth User. As part of this, I want to include the ability to register for a new user account using an OpenID instead of a password. At the moment, django.contrib.auth does not support creating a user account without setting a password. OpenID is not the only use case where password-less accounts might be warranted. Any application where authentication takes place against an external source - for example, authenticating against an existing LDAP provider - would also benefit from being able to create Django user accounts without setting a password. I propose the following changes: 1. The 'password' field in the User model should be altered to have blank=True. This would allow us to set blank passwords as an empty string. It would not require existing installations to make any schema changes as the column would still be NOT NULL. 2. user.set_password(password) should be altered to accept 'None' If None is passed to the function, a blank string will be stored instead of an encrypted password. 3. user.has_password() should be added A simple utility method which returns True if the user has a password, False if they do not. 4. check_password should ALWAYS return False if no password is set This should help protect us from introducing any security issues with these changes. Does this sound like a workable plan? If so, I'd like to get the changes in as soon as possible so I can wrap up work on the next version of the OpenID package. Cheers, Simon --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: When will updatedb be completed?
On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote: > Do any of you guys when the django-admin.py updatedb command will be > completed? updatedb is basically all django is missing for me and many > developers at the company I work for to abandon CakePHP and move to > django. As far as I know, none of the core development team are actively working on any form of automated schema evolution. There is a branch, but it is the responsibility of a volunteer who was writing the code; if you're interested in seeing that code completed, the best thing to do is contact the person who was working on it and see about collaborating to finish the work. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
When will updatedb be completed?
Do any of you guys when the django-admin.py updatedb command will be completed? updatedb is basically all django is missing for me and many developers at the company I work for to abandon CakePHP and move to django. Thanks, Sebastian --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
Re: "While I'm not saying that multiple DB-level users and DB-level access controls are the wrong solution, I would ask up-front what specific real-world problem is being solved by this, and whether it really is the best solution." At the company I'm currently working for, we have a 'sister' company, which we receive some data. For legal purposes, they must 'own' that data, and it must reside on separate database servers. The web app I'm creating for the my company (which will also be used as a tool by our 'sister' company), has the need to view/update data from both databases. Just wanted to give a real-world scenario in response to the question On May 10, 1:35 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > It's a tightly modelled, configurable, business administration tool. > > If used in a business of significant size, I would expect and hope > > that a DBA was employed to administer the database. Many of the tables > > will contain information that is restricted (sometimes with different > > scope for readability and editablility) to various roles which are > > mapped to individuals or groups in the organisation. > > While I'm not saying that multiple DB-level users and DB-level access > controls are the wrong solution, I would ask up-front what specific > real-world problem is being solved by this, and whether it really is > the best solution. > > Rambling historical anecdote: > > Many large organizations have IT policies which require users to > change their passwords every so often, usually once every 30 or 90 > days. This is touted as a security requirement for sensitive data, and > it's rare that anyone asks what actual security problem the password > changes solve. As it turns out, the origin of this recommendation was > an analysis of how long it would take to brute-force a password on a > 1970s-era mainframe -- the recommended period for changing passwords > was set to be shorter than the time it would take to try every > possible password. > > Modern systems are far faster, and brute-forcing a password can now be > a matter of hours or even minutes. Newer, stronger methods -- such as > better physical and network security controlling access to the system, > and "locking out" a user after a relatively low number of failed login > attempts -- now mitigate this risk far more effectively than any > "change your password every X days" policy. Additionally, such a > policy actually increases the risk of a breach -- frequent password > changes encourage users to choose weaker passwords, or to write down > their passwords and leave the information in easily-accessible places. > > But most companies still have a mandatory password-change policy, > because the organizational inertia of "we've always done it that way, > and everybody else does it that way" discourages questioning. > > Similarly, I have a feeling that segregation of databases and the sort > of access controls you're proposing have their roots in much older > systems where users had more or less direct access to the database > server and this was the most effective way to manage the users. > > But modern applications almost invariably introduce a mediating layer > between the user and the database, effectively moving access controls > to another layer of the stack. For example, in a web application a > user can only access data through the interface exposed by the > application; there's no way to "drop down" and avoid that layer. This > means that the application can control access and hide implementation > details in much the same way as database-level views and stored > procedures. > > This is why so many web applications use only a single logical > database, and access it through a single database-level user; the > application logic should already be taking some access controls into > account (for example, if the user isn't allowed to view records from a > particular table, the application should never even display an option > to do so) anyway, so moving more access-control logic to the > application layer becomes a more attractive option. > > Moving access-control logic "up the stack" into the application layer > also increases the flexibility you have when designing and optimizing > the database (since you're not bound to a particular design from the > start), and allows easier modification of the application; with > pass-through authentication and DB-level segregated access, any change > to the authentication scheme must occur in two places: first, the > change must be made in the database layer, then corresponding changes > must be made in the application layer. By contrast, keeping as much > access-control logic as possible at the application layer means that > you have a single place where changes can be made (and remember that > application-level changes are often easier to manage than > database-level changes); this is the DRY principle at work. > > Given that,
Re: South American Developers
Hi, im from Chile, from Santiago ! Graphic designer... 2007/5/10, Mi Reflejo <[EMAIL PROTECTED]>: > > Yes, there are. At least one, but not in Chile. I'm in Argentina. > > Regards, > -- > Martín Conte Mac Donell > http://www.catartico.com > > > On 5/9/07, Josef <[EMAIL PROTECTED]> wrote: > > > > > > Are there any South American developers out there? Specifically in > > Chile? I'm looking to band together with a few locals to work on some > > fun consumer oriented web projects. > > > > > > > > > > -- RIMON BTL producciones Ronit Araujo G. Cel: 82292342 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Type coercion in Django
I think this discussion could use a bit of revival, as it seems
obvious to me that there are groups that could benefit from some sort
of field-level coercion. In addition to my DurationField and the
various possibilities available with GeoDjango, there are other things
that would be useful in various contexts.
Consider a ColorField that could store its value as an INTEGER for
efficiency, but allows Python to access it as a 3-tuple of (red,
green, blue). This could be done for both assignment and retrieval,
with the field dealing with everything in between using to_python and
get_db_prep_save. In fact, something like this is almost possible
already, with get_db_prep_save handling transmission into the
database, and get_db_prep_lookup dealing with lookup types. In theory
(with a good bit of work, I expect) it should be possible to search on
such a color field with something like
Model.objects.filter(color__red_gt=200) to get objects with a lot of
red in their color. That's probably a bad example given the SQL that
would be necessary to look up on part of an INTEGER while ignoring the
rest of it, but it shows what kind of out-of-the-box thinking would be
possible if the one missing component (to_python) were in place to
handle coercion into a proper Python type.
Another example would be a variant of XMLField that gives its contents
to Python as a minidom.Document object.
Now, I'll gladly admit that I'm throwing out possibilities that I,
myself, may not ever need, and I also know that there are ways to work
around this behavior outside the core of Django (like the mixin
examples provided for GeoDjango), and that Django is about solving
problems people actually encounter in the real world. However, for
DurationField at least, I am indeed experiencing this problem in the
real world. Maybe I'm just the first to consider storing audio
information in Django (though I doubt it), but it's a real situation
with real needs. YAGNI certainly doesn't apply here, as I definitely
am Gonna Need It.
I would also argue that while Django's focus on real-world problem-
solving is sound and just, it's getting a lot of criticism from people
who think it's not powerful enough for complex applications. While in
general I disagree with that criticism, things like this do
demonstrate its refusal to deal with what might seem like a very
simple, straightforward feature. I find it very odd that Django has
the capability to add custom field types, while (by design,
apparently) restricting their usefulness.
-Gul
On Apr 18, 8:26 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> On 4/19/07, jbronn <[EMAIL PROTECTED]> wrote:
>
>
>
> > The GIS branch (GeoDjango) is interested in type coercion.
> > Specifically, PostGIS returns geometries as hex strings to the client
> > -- it would be preferable to have this come into the model as either a
> > different type of string like WKT ("POLYGON ( .. )"), KML
> > ("...") or as a GEOSGeometry() object. For
> > example, say we have a 'ZipCode' model with a PolygonField ('poly'):
>
> Ok. That's the sort of use case I was looking for.
>
> I haven't looked at the GIS branch, and my GIS knowledge from
> university is getting _very_ rusty, so you'll need to help me out a
> little.
>
> How do you handle data input of GIS types? What format is used during
> assignment?
>
> Are you using to_python at all in the GIS branch?
>
> To date, the database backend maintains the philosophy that whatever
> you put in (as a python type) is what you get back. If you put a
> boolean in, you get a boolean out; you put a DateTime in, you get a
> DateTime out. Is this still appropriate in the GIS setting?
>
> Is there a use case for being able to get back data of more than one
> type, or is it possible to get a WKT or KML representation from a
> GEOSGeometry object?
>
> Yours,
> Russ Magee %-)
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: South American Developers
Yes, there are. At least one, but not in Chile. I'm in Argentina. Regards, -- Martín Conte Mac Donell http://www.catartico.com On 5/9/07, Josef <[EMAIL PROTECTED]> wrote: > > > Are there any South American developers out there? Specifically in > Chile? I'm looking to band together with a few locals to work on some > fun consumer oriented web projects. > > > > > --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
> Furthermore, in the general case, business logic is too complex to be > implemented simply in the database layer - significant business logic > would need stored procedures, triggers etc. which are inherently non- > portable across RDBMS platforms. Portability across RDBMS platforms is a pipe dream for anything except "happy apps". Forgive me for creating a serious database. If no-one here wants to talk to me about Django functionality, I'm not going to hang around. See you all, and thanks for the time you've taken to write your responses. On May 10, 5:25 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote: > On May 10, 7:37 am, foobarmus <[EMAIL PROTECTED]> wrote: > > > 1. RDBMSs like PostgreSQL, Oracle, perhaps even MySQL although it's > > still a fledgling in this regard (to name but 3), were designed to (or > > have subsequently been revamped to) handle the kind of business logic > > that large organisations demand. Web frameworks like Django invariably > > are not designed to handle such business logic. This is not a > > I'm probably misunderstanding something, but surely business logic is > the province of your application, and not of Django itself. > Furthermore, in the general case, business logic is too complex to be > implemented simply in the database layer - significant business logic > would need stored procedures, triggers etc. which are inherently non- > portable across RDBMS platforms. Also, in some scenarios, business > logic encompasses things which are not easily embeddable in the > database layer (e.g. sending out notification emails in a workflow > process). While Django is more focused on a model-driven approach from > which it works out and executes the SQL you need, there's no reason > you can't just use the urls and views part of Django and use e.g. DB- > API directly and provide complex business logic via code called from > your views. If you are using Django models, the model managers seem to > be the right place to put this kind of logic. > > Although Django does not yet provide all the hooks that are desirable > for some business needs - (e.g. support for views and stored > procedures and schema migration, a more generic authorization scheme) > it looks as if there is work in various branches towards providing > more functionality in at least some of these areas. > > My 2¢, > > Vinay Sajip --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On May 10, 7:37 am, foobarmus <[EMAIL PROTECTED]> wrote: > 1. RDBMSs like PostgreSQL, Oracle, perhaps even MySQL although it's > still a fledgling in this regard (to name but 3), were designed to (or > have subsequently been revamped to) handle the kind of business logic > that large organisations demand. Web frameworks like Django invariably > are not designed to handle such business logic. This is not a I'm probably misunderstanding something, but surely business logic is the province of your application, and not of Django itself. Furthermore, in the general case, business logic is too complex to be implemented simply in the database layer - significant business logic would need stored procedures, triggers etc. which are inherently non- portable across RDBMS platforms. Also, in some scenarios, business logic encompasses things which are not easily embeddable in the database layer (e.g. sending out notification emails in a workflow process). While Django is more focused on a model-driven approach from which it works out and executes the SQL you need, there's no reason you can't just use the urls and views part of Django and use e.g. DB- API directly and provide complex business logic via code called from your views. If you are using Django models, the model managers seem to be the right place to put this kind of logic. Although Django does not yet provide all the hooks that are desirable for some business needs - (e.g. support for views and stored procedures and schema migration, a more generic authorization scheme) it looks as if there is work in various branches towards providing more functionality in at least some of these areas. My 2¢, Vinay Sajip --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
syncdb should cleanup tables?!?!
I have Problems with old entries in "django_content_type". I described it here: http://groups.google.com/group/django-users/browse_thread/thread/4f74fc5a98f7c8fe/1b542eff91614ab8 I get the error "ContentType matching query does not exist." if i create a new user group. The Problem is: I had content types in my db without the corresponding model class. This happens, when you remove applications from your project or if you delete some model class in your app. There is a more detailed description in the german python-forum: http://www.python-forum.de/topic-10510.html I've hacked a standalone script to delete old entries in the tables "django_content_type" and "django_content_type": http://paste.pocoo.org/show/1482/ This it not enough. Other tables must be still updated: "auth_user_user_permissions", "auth_group_permissions", etc. Should that not do syncdb? Perhaps with an additional parameter, e.g.: "django-admin.py syncdb --cleanup=true" --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
> Ultimately, this is a tradeoff. What happens when another app wants to > use data from the same database but has less strict auth/access > requirements? So long as you know that only one application with only > one relatively-unchanging set of requirements will ever access the > database, you'll be OK, but the moment you have multiple apps, > multiple auth/access requirements or changes to the auth/access > requirements, the inflexible nature of hard-coding access at the DB > level will start causing you pain. Access requirements, in this context, represent a relationship between the business and the data. As such, they have nothing to do with any application that's putting its own arbitrary logic in-between. > By the same argument, the organization's DBA is also outside your > control and could just as easily wreak havoc. As the old saying goes: > when you invent an idiot-proof system, the world will compensate by > producing more advanced idiots. Funny, but getting back to the argument, DBAs are not idiots. The DBA's job in the organisation is to make the database run smoothly. On May 10, 3:23 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote: > > > Unfortunately, pushing access control up the stack means I > > have to rewrite all the functionality has been carefully and > > comprehensively facilitated by my RDBMS. Also it means that access > > control logic has to be written into every app that connects to the > > database - instead of just having it in the database itself. > > Ultimately, this is a tradeoff. What happens when another app wants to > use data from the same database but has less strict auth/access > requirements? So long as you know that only one application with only > one relatively-unchanging set of requirements will ever access the > database, you'll be OK, but the moment you have multiple apps, > multiple auth/access requirements or changes to the auth/access > requirements, the inflexible nature of hard-coding access at the DB > level will start causing you pain. > > > 2. When my app gets installed in an organisation, developers outside > > my control will be modifying and maintaining that instance. It would > > be easy for them to write an incorrect script that gave too much power > > to a user, and nothing would stop it from corrupting the database > > because of course with these "modern applications" the database > > connection is always made by a super-like-user that can do anything > > inside the application's database. > > By the same argument, the organization's DBA is also outside your > control and could just as easily wreak havoc. As the old saying goes: > when you invent an idiot-proof system, the world will compensate by > producing more advanced idiots. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: database connection user - newbie question
On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote: > Unfortunately, pushing access control up the stack means I > have to rewrite all the functionality has been carefully and > comprehensively facilitated by my RDBMS. Also it means that access > control logic has to be written into every app that connects to the > database - instead of just having it in the database itself. Ultimately, this is a tradeoff. What happens when another app wants to use data from the same database but has less strict auth/access requirements? So long as you know that only one application with only one relatively-unchanging set of requirements will ever access the database, you'll be OK, but the moment you have multiple apps, multiple auth/access requirements or changes to the auth/access requirements, the inflexible nature of hard-coding access at the DB level will start causing you pain. > 2. When my app gets installed in an organisation, developers outside > my control will be modifying and maintaining that instance. It would > be easy for them to write an incorrect script that gave too much power > to a user, and nothing would stop it from corrupting the database > because of course with these "modern applications" the database > connection is always made by a super-like-user that can do anything > inside the application's database. By the same argument, the organization's DBA is also outside your control and could just as easily wreak havoc. As the old saying goes: when you invent an idiot-proof system, the world will compensate by producing more advanced idiots. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On Wed, 2007-05-09 at 22:20 +, Mike Axiak wrote: > I have created a ticket specifically for newforms-admin and > edit_inline (#4255). > > I'd like to bounce ideas around in there, if people would be willing > to talk. I would partially be willing to do some implementation, but > don't want to write code other people have. > > http://code.djangoproject.com/ticket/4255 I really don't understand the idea behind these kinds of tickets (they've happened before and a few are still open for no good reason that I can see). You read this list, Mike. Hopefully you noticed that Adrian and Joseph K have mentioned they worked out a plan at PyCon this year and Joseph started committing some code as a result of that, although it's possible you have forgotten until just now. Opening a ticket is either some subtle form of "please hurry up", which is uncalled for, or just another open ticket that achieves nothing except adding to the number of open tickets. Discussion will happen on the list, not in the ticket. It's not like we don't know that feature is missing from newforms-admin. So what value does it add? Okay, one of the guys involved with implementing that code could respond to your requests, but it happens from time to time that in the enormous level of e-mail on this list, combined with the business of daily life, things get overlooked for a little while. I do know that Adrian periodically goes through his django-dev email and responds to relevant threads. So a little patience is appropriate here. Please close it off. Thanks, Malcolm --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
