Re: One Grateful New Djangotist Agrees
Which framework did I personally spend heaps of time investigating, book-buying and ultimately reject for my own purposes? --~--~-~--~~~---~--~~ 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: One Grateful New Djangotist Agrees
On 19-Jun-06, at 2:04 PM, jorjun wrote: > > Which framework did I personally spend heaps of time investigating, > book-buying and ultimately reject for my own purposes? yes - we are all ears -- regards kg http://lawgon.livejournal.com http://avsap.org.in --~--~-~--~~~---~--~~ 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: One Grateful New Djangotist Agrees
On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > yes - we are all ears Meh. The book-buying is a giveaway. -- "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: One Grateful New Djangotist Agrees
On 19-Jun-06, at 2:38 PM, James Bennett wrote: > > On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: >> yes - we are all ears > > Meh. The book-buying is a giveaway. ahh - monday morning, forgive me ;-) -- regards kg http://lawgon.livejournal.com http://avsap.org.in --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ticket #2197: Generic search interface
Hello. I have submitted a patch to ticket#2197[0]. Any comments? Does anyone else think this is useful to have in django? [0] http://code.djangoproject.com/ticket/2197 --~--~-~--~~~---~--~~ 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: Ticket #2197: Generic search interface
On 6/19/06, Matias Hermarud Fjeld <[EMAIL PROTECTED]> wrote: > I have submitted a patch to ticket#2197[0]. Any comments? Does anyone > else think this is useful to have in django? It's a useful thing, but... We've got a Summer of Code project working on a true search-engine-like system to integrate into Django, which would provide searching capabilities far beyond what the database API offers. So this might end up being redundant. -- "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: validate_full never called?
On 6/17/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > On 6/17/06, gabor <[EMAIL PROTECTED]> wrote: > > > > could you post your model and the relevant part of the view code? > > The relevant model: class Product(models.Model): product_name = models.CharField(maxlength=64, blank=False,validator_list=[good_name], unique=True, primary_key=True) And my view: if request.POST: manipulator = Product.AddManipulator() new_data = request.POST.copy() errors = manipulator.get_validation_errors(new_data) if not errors: manipulator.do_html2python(new_data) When I have the primary_key=True, then the manipulator doesn't catch any errors. It also doesn't call my 'good_name' validator. When I remove the primary_key=True, then the manipulator catches the error, and returns "This field is required." as the field error. Jay P. --~--~-~--~~~---~--~~ 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: Ticket #2197: Generic search interface
On 19 Jun 2006, at 13:25, James Bennett wrote: > We've got a Summer of Code project working on a true > search-engine-like system to integrate into Django, which would > provide searching capabilities far beyond what the database API > offers. So this might end up being redundant. Will the Summer of Code project include some kind of fall-back for when a proper full-text indexing system isn't available? (Something trivial based on LIKE queries). For small sites the .search() method would be very useful. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Great Link for Perfect Career
Hello Now, I am sharing with you another website that is excellent for IT Jobs. Currently, this website has 6000 IT Jobs. Please check this link and enjoy your dream job. www.it-jse.com Special thing about this website is, they are presenting direct links to jobs. They are using only Direct Employers and not using Staffing Companies, Contract firms, Agencies, recruiters. regardsBruce Smith --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
DateField comparison broken?
I posted this on django-users, but didn't get much feedback. It seems
like a pretty important problem, so I'm reposting here:
My current model looks like this:
class Article(models.Model):
title = models.CharField(maxlength=64)
slug = models.SlugField(prepopulate_from=("title",))
author = models.ForeignKey(User)
text = models.TextField()
pub_date = models.DateField()
public = models.BooleanField()
def get_absolute_url(self):
return "/articles/%s/%s/" %
(self.pub_date.strftime("%Y/%m/%d"), self.slug)
I was using the date_based generic views when I noticed that something
was quite wrong. Whenever I used the archive_day or object_detail, no
results were being returned!
As an example, I created an entry in the Admin with a Date of
2006-01-16 and a slug of "foo". If I went to
/articles/2006/01/
then I would see my entry in the object_list.
However, if I go to /articles/2006/01/16/ or
/articles/2006/01/16/foo, it doesn't work (I get a 404 error)
I've dug a little deeper, and got the following worrying results in the shell:
ln [14]:x = Article.objects.all()
In [15]:x.filter(pub_date__range= (datetime.datetime(2006,1,16,0,0),
datetime.datetime(2006,1,16,23,59,59,99)))
Out[15]:[]
In [16]:x.filter(pub_date__range=
(datetime.datetime(2006,1,15,23,59,59,99),
datetime.datetime(2006,1,16,0,0,0,0)))
Out[16]:[]
That query on line 15 is the exact same query that archive_day uses.
So my article, with a pub_date of 2006-01-16 does NOT show up in the
results of the first query, but does in the second. Looks like the
comparison code somewhere is broken.
Note, I'm using sqlite3.
Jay P.
--~--~-~--~~~---~--~~
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: RFC: Django history tracking
Uros Trebec wrote: > class Post(models.Model): > author = models.CharField(maxlength=100) > title = models.CharField(maxlength=100) > content = models.TextField() > date = models.dateField() hi, sorry to jump in so late into the discussion, but right now i'm in a situation where maybe model-history is the answer. a question: what about ForeignKeys and ManyToManyFields? how do you propose to version those? what if a ForeignKey-relation changes? gabor --~--~-~--~~~---~--~~ 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: Ticket #2197: Generic search interface
On 6/19/06, Simon Willison <[EMAIL PROTECTED]> wrote: > Will the Summer of Code project include some kind of fall-back for > when a proper full-text indexing system isn't available? (Something > trivial based on LIKE queries). For small sites the .search() method > would be very useful. Jacob's mentoring that project, so hopefully he'll pipe up and answer this :) -- "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 -~--~~~~--~~--~--~---
branch request: generic-auth
I'd like to get a branch started for my summer of code project. It's not urgent, but something in the next couple of days would be great. http://code.djangoproject.com/wiki/GenericAuthorization Thanks, 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 -~--~~~~--~~--~--~---
Re: Regressions tests: a suggestion
Malcolm Tredinnick wrote: > What I would like to propose is that we create a tests/regression/ > subdirectory for these slightly more mind-numbing but important tests. > Same sub-directory structure, etc, as the the modeltests/ directory, but > not in any way intended to be examples of good model technique. +1 -- there are already a few cases where I've added tests into the modeltests that don't really belong there -- I've generally made it clear what they are, but it would be good to split them out. Regards, Luke --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Recursive delete problem
Don't know why Django's ORM works in this way, but I think this may be a bug... This is how my model looks like: #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - class Score(models.Model): . . . class Round(models.Model): . . . class Game(models.Model): round = models.ForeignKey(Round) . . . def save(self): """ Recompute the scores in the Score table """ def delete(self): """ Recompute the scores in the Score table """ #- - - - - - - - - - - - - - - - - - - - - - - - - - - - - When I delete a game, with game.delete() (or through the admin, generic_view...), delete method is called and the Score table is updated. But when I delete a round, with round.delete(), all games conected with that round are also deleted, but the Score table isn't updated, i.e. the delete() method from the game objects is not called?!?! That is, django just deletes all related rows from database, without caring about the object properties of the row... Django's ORM is not about tables, columns and rows... It's about objects (or I'm missing something :)... So, when I delete an object from my "persistent memory" (db or whatever), and that object has a "destructor" (in this case delete method), I'm sure that it's desirable to call that "destructor"... --~--~-~--~~~---~--~~ 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: Regressions tests: a suggestion
On 6/18/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > What I would like to propose is that we create a tests/regression/ > subdirectory for these slightly more mind-numbing but important tests. > Same sub-directory structure, etc, as the the modeltests/ directory, but > not in any way intended to be examples of good model technique. Sounds like a good idea. Go for it! Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
PostgreSQL Schema search_path Support (#1051)
Ticket #1051 adds support for setting the schema search path on PostgreSQL connections. I've updated the patch for the current HEAD. It would also be interesting to look into per-application schema search_path support, so one could have the admin app live in the admin schema, as opposed to prepending 'admin_' to the table names. However, that's a fair bit more complicated than a 3-line patch, and #1051 won't get in the way. -landonf PGP.sig Description: This is a digitally signed message part
Re: One Grateful New Djangotist Agrees
I am sure you have it now. But just to make sure, the next clue is that it sounds a bit like "soap and phone" ;0) --~--~-~--~~~---~--~~ 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: One Grateful New Djangotist Agrees
On 19-Jun-06, at 11:28 PM, jorjun wrote: > I am sure you have it now. But just to make sure, the next clue is > that > it sounds a bit like "soap and phone" ;0) then nobody got it - because *that* is not a framework - it is an application server, which is a totally different kettle of fish -- regards kg http://lawgon.livejournal.com http://avsap.org.in --~--~-~--~~~---~--~~ 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: One Grateful New Djangotist Agrees
On 6/19/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > then nobody got it - because *that* is not a framework - it is an > application server, which is a totally different kettle of fish Yeah. I was thinking "Booby on Whales". Some things have a learning curve. Zope has a learning asymptote. -- "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: Proposal: default escaping
To better detail the "in the model" idea: An additional field type would be added, extending CharField, called say "HTMLSafeField". It would strip/escape/convert/reject invalid strings both when being set and when being read. Otherwise it would behave just like a CharField. The key is not to think of it as an escaping mechanism; simply as a data validity check. And there is ample precedence for this in Django. What are EmailFields, PhoneNumberFields and SlugFields if not simply CharFields that match a regex? "Intro" users who are not able to grok XSS can simply be told to always use HTMLSafeFields instead of CharFields. Converting existing apps would be simple model-only search-and-replace exercises. Folks who don't like wrapper tags around all variables in templates will be appeased. (as will those who don't want "escape=on" tags at the top of every template) And I (and my like-minded kin) who think both "breaking every template==bad" and "magic behind the scenes==worse" will not vomit at the addition. Likewise XMLSafeField, JavascriptSafeField, MustMatchUserRegexField, etc. would be logical extensions. The biggest downside is if you want valid HTML data stored for one output type and escaped for another. But this is not a scenario I've ever seen in the real world, and regardless is easily worked around with simply returning to CharFields for that one attribute. (and manually escaping of course) What do you think? -- Derek --~--~-~--~~~---~--~~ 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: default escaping
On 19 Jun 2006, at 20:18, [EMAIL PROTECTED] wrote: > The biggest downside is if you want valid HTML data stored for one > output > type and escaped for another. But this is not a scenario I've ever > seen > in the real world, and regardless is easily worked around with simply > returning to CharFields for that one attribute. (and manually > escaping of > course) > > What do you think? I'm not keen on escaping being controlled by the model - escaping should be a template-level decision as that's when you decide what format is being output (plain text email / HTML / XML / LaTeX for PDF conversion etc). I played around with some proof of concepts over the weekend and I think I have some ideas that should keep most people happy. I'll try to write them up on the wiki this evening. 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 -~--~~~~--~~--~--~---
Re: RFC: Django history tracking
Uros Trebec wrote: > 2.1. Basic models: > To enable history tracking Bob has to create a sub-class for those > models that he will like to track: > > class Post(models.Model): > author = models.CharField(maxlength=100) > title = models.CharField(maxlength=100) > content = models.TextField() > date = models.dateField() > > class History: > pass > > This works much like using Admin subclass. The difference is that if > the subclass is present then database will have change to include two > tables for this class: > > (the main table - not changed): > > CREATE TABLE app_post ( > "id" serial NOT NULL PRIMARY KEY, > "author" varchar(100) NOT NULL, > "title" varchar(100) NOT NULL, > "content" text NOT NULL, > "date" datestamp NOT NULL > ); > > > (and the history table): > > CREATE TABLE app_post_history ( > "id" serial NOT NULL PRIMARY KEY, > "change_date" datestamp NOT NULL, # required for datetime > revert > "parent_id" integer NOT NULL REFERENCES app_post (id), > "author" varchar(100) NOT NULL, # data from app_post > "title" varchar(100) NOT NULL, # data from app_post > "content" text NOT NULL,# data from app_post > "date" datestamp NOT NULL # data from app_post > ); > > I think this would be enough to be able to save "basic full" version of > changed record. Although you have a date field in your example model it might not hurt to add an automatic timestamp to a model that uses versioning in this way. One that relies on a "data" field that could be changed by a user doesn't seem safe to me. I'd also like an automatic userid stamp on there over and above the "author" which again is a data field not a hidden system field. You might also consider some automatic "revision number" system which increments every time the record is changed. This makes it easier to "roll back" to the previous entry and can be a lifesaver if something happens to whatever is providing the dates. > 2.2. Selective models: > But what if Bob doesn't want to have every information in history (why > would someone like to keep an incomplete track of a record is beyond > me, but never mind)? Me either. Suggests that this may be a non-feature? I think the framework suggested is a great start. I would be interested in seeing a feature that tied changes not just to the user who made the change but also to the "session" that they made the change in. i.e. if my system allows "Dave" to have two active sessions at different computers I'd like to track what he did in each session not just what date the changes occurred. This is very helpful for user complaints and fraud detection. --~--~-~--~~~---~--~~ 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: default escaping
> I'm not keen on escaping being controlled by the model - escaping > should be a template-level decision as that's when you decide what > format is being output (plain text email / HTML / XML / LaTeX for PDF > conversion etc). > > I played around with some proof of concepts over the weekend and I > think I have some ideas that should keep most people happy. I'll try > to write them up on the wiki this evening. that's why i suggest looking at this as a data validation issue. (not simply as escaping) we do lots of validation in the model already. (some argue that *all* data validation should be in the model) this would just be an additional type. anyway, i suppose i will wait for you to elaborate on your reasoning in the wiki this evening. :) --~--~-~--~~~---~--~~ 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: DateField comparison broken?
Jay Parlar wrote:
> I posted this on django-users, but didn't get much feedback. It seems
> like a pretty important problem, so I'm reposting here:
>
> My current model looks like this:
>
> class Article(models.Model):
>title = models.CharField(maxlength=64)
>slug = models.SlugField(prepopulate_from=("title",))
>author = models.ForeignKey(User)
>text = models.TextField()
>pub_date = models.DateField()
>public = models.BooleanField()
>
>
>
> As an example, I created an entry in the Admin with a Date of
> 2006-01-16 and a slug of "foo".
>
>
> ln [14]:x = Article.objects.all()
>
> In [15]:x.filter(pub_date__range= (datetime.datetime(2006,1,16,0,0),
> datetime.datetime(2006,1,16,23,59,59,99)))
> Out[15]:[]
>
> In [16]:x.filter(pub_date__range=
> (datetime.datetime(2006,1,15,23,59,59,99),
> datetime.datetime(2006,1,16,0,0,0,0)))
> Out[16]:[]
>
>
>
> Note, I'm using sqlite3.
>
that seems to be the problem.
it works with postgresql.
if you want to verify the problem:
import django.db
print django.db.connection.queries
this will print out the sql queries django is doing.
in this case it does something like this:
select * from main_article where pub_date between '2006-01-16 00:00:00'
AND '2006-01-16 23:59:59.99';
if you execute this query directly on the sqlite3 database, it will not
find anything.
if you repeat this example in postgresql, it works.
so it seems to be a bug with sqlite3... will dig around a little more.
gabor
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Documentation improvement
I suppose it gets brought up a lot I figure I should bring it up too so it happens :) I think it'd be really cool if there were a central reposatory of links to off site tutorials and screen casts with a rating and tagging system. That way say I created a tutorial I could go to the site, and add it, put in who it's for, what version of django what it covers etyc and then people could find it easier. It should store data about the tutorials like who it's by, what level of django user it's for, any special requirements etc. But the real key for this would it'd need to be right on the documentation page so newbies could find it easily. Say a new user hears about django and says "Gosh I'd like to try that out" He goes to the current site and sees the current tutorial and it's ok but he wants more, sort of a "show mne again only with more detail" kind of a thing He could see Oh look "How to clone WordPress in 4 Hours Or Less" For "Begginners" and it would once again walk him through everything from creating the project to making a fully usable, skinned, good looking blog. Something he can use. Maybe he's good and now he wants to extend the user permissions system of django he could just go and look for a tutorial. Many people learn better from tutorials than reading docs. By linking to offsite tutorials it takes the burden off of the django site to manage, maintain etc. The same "registry" could contain screen casts etc. --~--~-~--~~~---~--~~ 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: DateField comparison broken?
On 6/19/06, gabor <[EMAIL PROTECTED]> wrote: > > > that seems to be the problem. > it works with postgresql. > > if you want to verify the problem: > > import django.db > print django.db.connection.queries > > this will print out the sql queries django is doing. > > in this case it does something like this: > > select * from main_article where pub_date between '2006-01-16 00:00:00' > AND '2006-01-16 23:59:59.99'; > > if you execute this query directly on the sqlite3 database, it will not > find anything. > > if you repeat this example in postgresql, it works. > > so it seems to be a bug with sqlite3... will dig around a little more. > It felt like a db error, because of *where* it was breaking, but I've not yet looked into the ORM layer, and didn't have time to start digging. Jay P. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Silent dropping of foreign keys (Ticket #1928)
Database creation is silently dropping foreign key constraints where there is more than one reference to the same primary key -- I only caught the issue thanks to my unit tests. Is the patch attached to #1928 a reasonable fix? It'd be great to get this committed; it seems like a fairly serious bug. -landonf PGP.sig Description: This is a digitally signed message part
Re: DateField comparison broken?
On 6/19/06, Jay Parlar <[EMAIL PROTECTED]> wrote: > It felt like a db error, because of *where* it was breaking, but I've > not yet looked into the ORM layer, and didn't have time to start > digging. This feels like a reawakening of some old bugs that had to do with matching dates in SQLite; I forget exactly how they were resolved, but I'll put in some research on it. -- "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: RFC: Django history tracking
Hi! > There was a similar thread on this earlier where I commented about a > slightly different way to store the changes: > http://groups.google.com/group/django-users/browse_thread/thread/f36f4e48f9579fff/0d3d64b25f3fd506?q=time_from&rnum=1 Thanks for this one, I already found something usefull. > To summarize, in the past I've used a time_from/time_thru pair of > date/time columns to make it more efficient to retrieve the version of > a row as it looked at a particular point in time. Your design of just > using change_date makes this more difficult. I don't know what you mean exactly, but I'm not using just change_date. The ID in *_history table defines the "revision/version number", so you don't have to use "change_date" to get the exact revision. > I can also think of use cases where I want the versioning to track both > date and time since I would expect multiple changes on the same day. This one is my fault. What I meant was using datetime for that field, for said reasons exactly. Good catch! > Maybe these could also be options? Such ideas are always welcome. I will try and make it as versatile as possible. Regards, Uros --~--~-~--~~~---~--~~ 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: RFC: Django history tracking
> Sounds nice, this is a feature I'm currently looking for... but I've
> already started my own implementation.
Nice! Do you have anyting in code yet? Any bottlenecks?
> I would just share it with you.
>
> I've build a single table History with :
> - "change"; a text field which will contain a python pickled
> dictionary: { field: old_value} in case you update a record.
How does this help/work? Why dictionary? Can you explain?
> - type: type of modification (update, delete, insert).
Is this really necesary? How do you make use of it?
> - "obj": the table object. This can come from ContentType
I don't understand...
> - "obj_id": the id of the impacted object.
> - create_date: a timestamp automatically set.
> I'm using it by sub-classing the save methods in each model I want to
> see the history.
> This is quite flexible, because you can decide which field you want to
> track.
I agree. But I fail to see the need for not versioning the whole record/row.
> To facilitate, yet one step further, it would be nice to have a
> PickledField within Model.models of django.
Can you elaborate on that?
> Feedbacks are welcome.
Same here! :) And thanks for your feedback!
Regards,
Uros
--~--~-~--~~~---~--~~
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: RFC: Django history tracking
Hi! > Great to see that your RFC is pretty much exactly what I was thinking > (feature and implementation-wise) when I posted > http://roups.google.com/group/django-developers/browse_thread/thread/d90001b1d043253e/77d36caaf8cfb071 I'm glad! Thanks for the link too. > It would be nice to record "who" made the change (optionally when there > is a user with an id available). I was thinking of not pushing the use of such fields, because there is no easy way to figure out how each applications handles accounts/users. But it's something that it should be made possible with additional/custom fields, IMHO. > I thought that storing complete row copies on both inserts and updates > to original object isn't that bad - it certainly simplifies the > machinery. This is true. > Because the way I was considering using this feature would > read history tables very infrequent their size wasn't a big factor in > my mind. I'm sort-of undecided about this. On one hand you can potentialy have a lot more data to handle, but on the other, you don't need multiple SELECTs and merging happen when you want a version from way back. What do others think about this? > An admin to view change history "diff" colored output and to revert to > arbitrary previous version would be an obvious future addition. I agree. And I do have it on my todo list, but it's not "feature critical", so it will have to wait until the machinery is done. Or maybe not... hmm... Regards, Uros --~--~-~--~~~---~--~~ 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: RFC: Django history tracking
On 6/19/06, IanSparks <[EMAIL PROTECTED]> wrote: > Although you have a date field in your example model it might not hurt > to add an automatic timestamp to a model that uses versioning in this > way. Changing the versioned model because of use of versioning is something I would like to avoid. Forcing such things might not be a good idea. But if there is no other way... > One that relies on a "data" field that could be changed by a user > doesn't seem safe to me. I don't know what you mean by this? > I'd also like an automatic userid stamp on there over and above the > "author" which again is a data field not a hidden system field. As I said before, this is not something that can be easily done, because various ways of user/account handling. Or am I missing the point here? > You might also consider some automatic "revision number" system which > increments every time the record is changed. This makes it easier to > "roll back" to the previous entry and can be a lifesaver if something > happens to whatever is providing the dates. Every record in *_history table has its own ID which I was going to use as "revision number". And to make it easier to find "previous revision" I was thinking on adding a "prev_rev" column to the table. What do you think? Would this be enough? > I think the framework suggested is a great start. I would be interested > in seeing a feature that tied changes not just to the user who made the > change but also to the "session" that they made the change in. i.e. if > my system allows "Dave" to have two active sessions at different > computers I'd like to track what he did in each session not just what > date the changes occurred. This is very helpful for user complaints and > fraud detection. Hmm, very interesting idea! Do you have any suggestions on how would this be best implemented? I must admit, I don't have much knowledge how Django works internally so any help that I can get would be very appreciated! Thanks! Regards, Uros --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Tackling ZODB support in Models
I've been developing some fun stuff with django for about a month now and I've been thinking of taking on a big challenge, adding ZODB support to Models. I _love_ the django models, but there are a few things I wish to do in which I need a full object persistence. I'm sending this to the list before diving head in to this task because I'm wondering: a) Is there someone already doing this :) b) Can anyone see right away huge issues that I'll run in to in the implementation. and c) Is this going to be significantly harder now rather than later. What I mean is, is there already good support for going in and supporting a new DB type that isn't likely to change much before 1.0 or should I just wait until 1.0 For those that don't know, or just cringe at the mention of something from Zope, ZODB is a very cool, very modular multi-use object persistence database. The advantage to using it would be that you could dynamically create python objects and store them in your chosen storage (filesystem, subversion, BerkeleyDB, etc) and reap the benefits of persistence and indexing. -Mikeal --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
trac updates/changesets not being sent?
hi. I just noticed that the last email I got from django-updates was on june 12. has something been turned off ? regards Ian --~--~-~--~~~---~--~~ 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: default escaping
[EMAIL PROTECTED] wrote: > that's why i suggest looking at this as a data validation issue. (not > simply as escaping) we do lots of validation in the model already. But it is an escaping issue. There's nothing wrong with allowing html to be entered in (for example) a comment field. It should be escaped in most templates, but sometimes not, for example if there was a plain-text email of comments that gets sent. --~--~-~--~~~---~--~~ 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: Development Growing Pains: Patch Acceptance
On 6/18/06, Landon Fuller <[EMAIL PROTECTED]> wrote: > So, my plea: I like Django, and I'd like to put a lot of resources > behind using and improving it. If new committers were pulled from the > ranks of solid contributors, new users of Django (like me!) could be > assured that their contributions won't languish, and we won't run > into nasty bugs that have already been found and fixed by another user. Hey Landon, Thanks for the comments. I'd like to restructure our Trac installation into more useful categories, such as: "Still thinking about it," "Patch is good and should be committed with caveats," "Patch isn't good enough," and stuff like that. I think more granular categories like that would help us get more on top of the tickets/patches. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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: RFC: Django history tracking
> > It would be nice to record "who" made the change (optionally when there > > is a user with an id available). > > I was thinking of not pushing the use of such fields, because there is > no easy way to figure out how each applications handles > accounts/users. and > > I'd also like an automatic userid stamp on there over and above the > > "author" which again is a data field not a hidden system field. > > As I said before, this is not something that can be easily done, > because various ways of user/account handling. Or am I missing the > point here? I think using django.contrib.auth's user id (when available) would be satisfactory for most people. --~--~-~--~~~---~--~~ 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: Regressions tests: a suggestion
On Mon, 2006-06-19 at 12:28 -0500, Adrian Holovaty wrote: > On 6/18/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > What I would like to propose is that we create a tests/regression/ > > subdirectory for these slightly more mind-numbing but important tests. > > Same sub-directory structure, etc, as the the modeltests/ directory, but > > not in any way intended to be examples of good model technique. > > Sounds like a good idea. Go for it! I've done this in r3176. It seems to actually require some tests in each directory for the framework to not explode, so I couldn't commit just the runtests.py changes and then the first bunch of tests. :-( Because of the way tests are imported in runtests, it is currently not possible to have a subdirectory of modeltests/ and a subdirectory of regressiontests/ with the same name (so, for example, I created regressiontests/one_to_one_regree/ ). If somebody wants to play around with that and fix it, be my guest; I intend to just leave it as a slight wart for now. 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 -~--~~~~--~~--~--~---
Re: Proposal: default escaping (and branch request)
On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote: > anyway, i suppose i will wait for you to elaborate on your > reasoning in > the wiki this evening. :) I've written up a proposal for how we can implement auto escaping while hopefully keeping most people happy: http://code.djangoproject.com/wiki/AutoEscaping It incorporates stuff from a whole bunch of prior discussions. In my opinion the most important aspect is the use of special escapedstr and escapedunicode subclasses to mark a string as having been already escaped, meaning that the auto escaping mechanism knows if it should kick in to action or not. This should also avoid double escaping, and allow a decent level of finely grained control over the escaping mechanism. I'd like to get a branch going to explore this stuff properly. From messing around with my own local code it seems like it should all work, but there's a bunch of work that needs to be done to make existing Django filters and templates auto escape compliant. 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 -~--~~~~--~~--~--~---
