how to make two text boxes appear on a single row
Hi, I am new to django and i want to make two text boxes appear on the same row , what should i have to do for it, please help me out. --~--~-~--~~~---~--~~ 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: how to make two text boxes appear on a single row
On Wed, May 21, 2008 at 3:55 PM, amar <[EMAIL PROTECTED]> wrote: > > Hi, >I am new to django and i want to make two text boxes appear on the > same row , what should i have to do for it, please help me out. Please don't ask how-to questions on Django-developers. Django Developers is for discussing of the development of Django itself. Please direct how-to questions to the Django-Users mailing list. 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 -~--~~~~--~~--~--~---
two text boxes on the same row
I am doing a project on django and now i want to show two text boxes on the same row, please help me how to do it. --~--~-~--~~~---~--~~ 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: Rethinking silent failures in templates
On Wed, May 21, 2008 at 5:27 AM, Curtis <[EMAIL PROTECTED]> wrote: > > > Has anyone considered using Python's 'warnings' module? It seems like > it might be the perfect fit for this problem. > > For example, if the appropriate warn() calls were added to the > templating system, by default, problems would be sent to sys.stderr. With the little exception that writing to stdout or stderr from a fcgi/wsgi application will kill your application server with a nice "broken pipe" when deployed on production :) -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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: Proposal: Form rendering with filters
Just a quick bump: has there been any progress on this? Thanks, Aral On Apr 11, 9:44 pm, Brian Beck <[EMAIL PROTECTED]> wrote: > Has anyone started working on this? I don't see a branch, but I'd > love to help out. I've also been writing similar tags and filters for > my form rendering (see [1]). > [1]:http://www.djangosnippets.org/snippets/693/ --~--~-~--~~~---~--~~ 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: Multiple database support
Hi all, I'll sort out the hg repo (it now needs to point at trunk - not qsrf) and trac project if I get time this evening and make it public readable for everyone who's interested. Is there a ticket in django we could use to track progress on this? We could use 4747, but if we do decide on a new API that might be a bit confusing... We could of course just use the mailing list and trac project, thoughts? It's great to see some interest in multiple db support again :-) Ben 2008/5/20 Nicola Larosa (tekNico) <[EMAIL PROTECTED]>: > > Daryl Spitzer wrote: > > If I don't, I see if I can at least make enough time to write up the API > > I came up with at PyCon. > > Please do, that would be great. > > -- > Nicola Larosa - http://www.teknico.net/ > > > > -- Regards, Ben Ford [EMAIL PROTECTED] +447792598685 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Howto create a custom Q object to implement fulltext
I've been a while trying to implement full-text search under
PostgreSQL, I created some code that works, but is not optimal.
I asked Malcolm Tredinnick and he told me:
"In fact, thinking about this a bit more, it might even be possible to
do
it all via a custom Q-like object. You might not need to do any
QuerySet/Query modifications. You can create a class that is passed to
filter() and exclude() calls, similar to how Q() is done now. That
class
really only has to support an add_to_query() method -- see the
Query.add_q() method to see how it's called. When add_to_query() is
called on your object, you have full access to the underlying Query
instance, so you can add table joins, add things to the where clause,
do
whatever you want."
But I can't do it, so ask for your help.
The code I have now is:
from django.db.models.sql.query import Query
from django.db import connection
class nQuery( Query ):
def get_from_clause(self):
r = super( nQuery, self).get_from_clause()
r[0].append(r", plainto_tsquery(%s) as query" )
r[1].append(r"'%s'" % (palabras,) )
return r
def full_text( self ):
select={
'headline': "ts_headline( %s, query,'StartSel
= , StopSel = ')" % ( 'content', ),
'rank': "ts_rank_cd(tsv, query, 32)",
}
self.add_extra( select,None,('tsv @@
query',),None,None,None )
q = nQuery( MyModel, connection )
q.full_text()
from django.db.models.query import QuerySet
items = QuerySet( MyModel, q ).order_by('-rank')
So what I want now is to create the custom Q-like object and get rid
of the previous code.
This Q object should have an add_to_query() method, where I have
access to the Query instance and I can modify everything.
Here is where the problem comes. I cant get an sql clause like this:
SELECT *, ts_headline( content_field, query,'StartSel = ,
StopSel = ')" ) as headline, ts_rank_cd(tsv, query, 32) as
rank FROM table_name,plainto_tsquery('words I want to search') as
query WHERE tsv@@ query.
Once this custom Q object is created, then we can use it like this:
FT( words='words I want to search' )
optionally we can pass parameters to retrieve the headline or not.
I'm completly stuck with this. I hope someone here can help me.
Thank you.
--~--~-~--~~~---~--~~
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: Multiple database support
> Is there a ticket in django we could use to track progress on this? We could > use 4747, but if we do decide on a new API that might be a bit confusing... > We could of course just use the mailing list and trac project, thoughts? There's also http://code.djangoproject.com/ticket/1142. With the mailing list and trac project, do we need a ticket for more than just a place to attach patches to invite others to test? > I'll sort out the hg repo (it now needs to point at trunk - not qsrf) and > trac project if I get time this evening and make it public readable for > everyone who's interested. Thanks Ben. -- Daryl On Wed, May 21, 2008 at 3:33 AM, Ben Ford <[EMAIL PROTECTED]> wrote: > Hi all, > > I'll sort out the hg repo (it now needs to point at trunk - not qsrf) and > trac project if I get time this evening and make it public readable for > everyone who's interested. > > Is there a ticket in django we could use to track progress on this? We could > use 4747, but if we do decide on a new API that might be a bit confusing... > We could of course just use the mailing list and trac project, thoughts? > > It's great to see some interest in multiple db support again :-) > > Ben > > 2008/5/20 Nicola Larosa (tekNico) <[EMAIL PROTECTED]>: >> >> Daryl Spitzer wrote: >> > If I don't, I see if I can at least make enough time to write up the API >> > I came up with at PyCon. >> >> Please do, that would be great. >> >> -- >> Nicola Larosa - http://www.teknico.net/ >> >> > > > > -- > Regards, > Ben Ford > [EMAIL PROTECTED] > +447792598685 > > > --~--~-~--~~~---~--~~ 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: QuerySet.update improvement.
On Sat, May 17, 2008 at 2:27 AM, Sebastian Noack <[EMAIL PROTECTED]> wrote: > I have released a new patch. See > http://code.djangoproject.com/attachment/ticket/7210/0001-Added-expression-support-for-QuerySet.update.3.patch. > > I still have to write tests and documentation, but I would like to hear > from Russel or the other maintainers, what they think about the code. What do I think? The code doesn't look fundamentally bad, but I'm not going to take a serious look until there are some test cases. Consider this from my point of view. I need to validate that your code works as advertised. As your patch currently stands, I need to write my own test cases, including coming up with some models, some test data, and thinking about the edge cases that need to be checked. This takes time - time that could be spent looking at someone else's code, merging someone else's patch. Given that my time is limited, and there are multiple demands on my time, it makes sense for me to concentrate on those patches that make my life easy, and enable me to process as many tickets as my limited time allows. Like I said last time, test cases are how you prove you are serious. It's how you prove to me that you've done more than a trivial analysis of the problem. It's how you prove to me that you've considered the edge cases. And for your own sanity, it's how you prove to yourself than when you make one of those "minor, this couldn't possibly affect anything" changes, that it actually doesn't change anything. 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: newforms-admin FormSet API
On Wed, May 21, 2008 at 5:56 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: > > Hello all, > > The newforms-admin branch is getting close to finalizing the formset > API. However, to do so we would like to run it by the developer > community for ideas. I have posted a diff [1] of documentation showing > the API. The diff shows the API without a leading underscore on the > factory functions. Meaning in source they are defined as: > > * _formset_factory > * _modelform_factory > * _modelformset_factory > * _inlineformset_factory > > Joseph and I believe that just dropping the leading underscore will be > good enough for a finalized API. What do others think of the API? My > documentation writing skills are *not* to be criticized :P However, > any errors or corrections to improve them would be greatly appreciated. I can't say I see a good reason for the underscore. They're public documented methods, not part of private API. Underscore begone, I say! However, that said: I might be missing something here, but we've just gone through the process of deprecating form_for_model and form_for_instance based upon the reasoning that a class based form definition is more flexible than trying to shoehorn everything into a factory method. Is there a reason that we are introducing a new set of factory methods rather than using a definition analogous to ModelForm? To that end, isn't modelform_factory an analog of form_for_model? Regarding the docs - I'm sure Adrian will apply his magic pencil, but as a first draft, it looks pretty good to me. One suggestion - the 'can_order' option needs a little more elaboration on how the order field can actually be used - i.e., how do I use the order field to effect organization in my children? 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: Using RawSQL-Models
On Fri, May 16, 2008 at 9:27 PM, Adrian R. <[EMAIL PROTECTED]> wrote: > > Okay, so I've got some additional information for you which are > hopefully useful for you. I've tried to switch to the dev version but > I don't think that I'm on the right way right now. I don't mean to be rude, but this isn't particularly helpful. A pageful of SQL doesn't really help me determine the problem you are having, or how a 'Raw SQL model' will solve the problem. Can you reduce your problem to a simple (or, at least, simplified) case? 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: newforms-admin FormSet API
Hi Brian, from our uses of the nfa, we found that these API are more than adequate for any use we could think of, which includes: generic edit inlines custom validation if both forms and formsets added logic (including fields) in forms (even in forms used in inline formsets) and model creation (.save* on formsets and forms) The thing we bumped into was located elsewhere - with inline formsets. If you wish to override the default behavior when it comes to saving the object, you have to define the methods on the formset, which doesn't make much sense to me - the form itself would definitely be a more logical place where to do this. Other than this slight logical inconsistence (in my eyes), the API is VERY usable and allowed us to do everything we wanted without unnecessary fuss. Thanks very much for the great work. Honza On Wed, May 21, 2008 at 3:44 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On Wed, May 21, 2008 at 5:56 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: >> >> Hello all, >> >> The newforms-admin branch is getting close to finalizing the formset >> API. However, to do so we would like to run it by the developer >> community for ideas. I have posted a diff [1] of documentation showing >> the API. The diff shows the API without a leading underscore on the >> factory functions. Meaning in source they are defined as: >> >> * _formset_factory >> * _modelform_factory >> * _modelformset_factory >> * _inlineformset_factory >> >> Joseph and I believe that just dropping the leading underscore will be >> good enough for a finalized API. What do others think of the API? My >> documentation writing skills are *not* to be criticized :P However, >> any errors or corrections to improve them would be greatly appreciated. > > I can't say I see a good reason for the underscore. They're public > documented methods, not part of private API. Underscore begone, I say! > > However, that said: I might be missing something here, but we've just > gone through the process of deprecating form_for_model and > form_for_instance based upon the reasoning that a class based form > definition is more flexible than trying to shoehorn everything into a > factory method. Is there a reason that we are introducing a new set of > factory methods rather than using a definition analogous to ModelForm? > To that end, isn't modelform_factory an analog of form_for_model? > > Regarding the docs - I'm sure Adrian will apply his magic pencil, but > as a first draft, it looks pretty good to me. One suggestion - the > 'can_order' option needs a little more elaboration on how the order > field can actually be used - i.e., how do I use the order field to > effect organization in my children? > > Yours, > Russ Magee %-) > > > > -- Honza Král E-Mail: [EMAIL PROTECTED] ICQ#: 107471613 Phone: +420 606 678585 --~--~-~--~~~---~--~~ 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: Rethinking silent failures in templates
'warnings' sounds like a subset of 'logging'. In a similar thread (about template tags and filters failing silently) two years ago Simon Willison (who started this thread) said: "We really need an official Django logging framework so stuff like this can be logged" http://groups.google.com/group/django-developers/browse_thread/thread/40adac6370fc195c/b1656b8e0c036c04 Maybe the right answer here is simply logging an info (or warning) message when a template can't find a value. Steven Armstrong has already mentioned it in this thread. And if Django had logging, we could have a SQL log, and I wouldn't have to start all my projects by setting up a logger, a SQL logging middleware, and an audit log of object create/update/delete. If there is support from on high for putting logging into Django, I'm more than happy to make the code changes. And I'm +1 on making tags fail loudly. 2008/5/21 Patryk Zawadzki <[EMAIL PROTECTED]>: > > On Wed, May 21, 2008 at 5:27 AM, Curtis <[EMAIL PROTECTED]> wrote: >> >> >> Has anyone considered using Python's 'warnings' module? It seems like >> it might be the perfect fit for this problem. >> >> For example, if the appropriate warn() calls were added to the >> templating system, by default, problems would be sent to sys.stderr. > > With the little exception that writing to stdout or stderr from a > fcgi/wsgi application will kill your application server with a nice > "broken pipe" when deployed on production :) > > -- > Patryk Zawadzki > PLD Linux Distribution > > > > --~--~-~--~~~---~--~~ 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: Proposal: Form rendering with filters
I'd like to know too. I especially liked both of Simon Willison's ideas of 1) Template tags for form rendering, and 2) Outputting and setting of a _doctype variable that the template tags use to decide what kind of HTML to output. If nobody has officially started anything, could we set up a Google code project with the hopes of this being included in Django once it's working and all the kinks are worked out? -Rob On May 21, 2:30 am, Aral Balkan <[EMAIL PROTECTED]> wrote: > Just a quick bump: has there been any progress on this? > > Thanks, > Aral --~--~-~--~~~---~--~~ 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: newforms-admin FormSet API
On Wed, May 21, 2008 at 8:44 AM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > However, that said: I might be missing something here, but we've just > gone through the process of deprecating form_for_model and > form_for_instance based upon the reasoning that a class based form > definition is more flexible than trying to shoehorn everything into a > factory method. Is there a reason that we are introducing a new set of > factory methods rather than using a definition analogous to ModelForm? > To that end, isn't modelform_factory an analog of form_for_model? Brian and I both tried to come up with a class based syntax to take care of formsets, but everything we came up with felt forced... like we were *just* doing it as an attempt at consistency. Our attempts actually made the implementation worse. This is one of the reasons Brian wrote the email though. If someone wants to propose a class based syntax, please do so. I'd love to see something better, and I have a hunch that there *is* a better way. I've been sitting on it for a few months now, and nothing has come to me. I'm probably too close to the problem though. For the record, it was just form_for_instance that I really wanted to see destroyed... form_for_model is actually pretty useful in some cases. You'll notice that there's no _for_instance analogues in the API ;) > Regarding the docs - I'm sure Adrian will apply his magic pencil, but > as a first draft, it looks pretty good to me. One suggestion - the > 'can_order' option needs a little more elaboration on how the order > field can actually be used - i.e., how do I use the order field to > effect organization in my children? Indeed. That might be a "not ready for primetime" feature right now. It doesn't work with models yet, and it might be better to provide a field class, or a widget for ordering and deletion. 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: Proposal: Form rendering with filters
On Wed, May 21, 2008 at 4:30 AM, Aral Balkan <[EMAIL PROTECTED]> wrote: > > Just a quick bump: has there been any progress on this? Not really. I started the implementation on the plane ride back from PyCon, realized that it wouldn't work *quite* the way I'd proposed (widgets don't have access to form data, only BoundFields do), and haven't gotten back to it yet. 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: Using RawSQL-Models
On 21 Mai, 15:50, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Fri, May 16, 2008 at 9:27 PM, Adrian R. <[EMAIL PROTECTED]> wrote: > > > Okay, so I've got some additional information for you which are > > hopefully useful for you. I've tried to switch to the dev version but > > I don't think that I'm on the right way right now. > > I don't mean to be rude, but this isn't particularly helpful. A > pageful of SQL doesn't really help me determine the problem you are > having, or how a 'Raw SQL model' will solve the problem. > > Can you reduce your problem to a simple (or, at least, simplified) case? I think that there isn't much more to explain, because today we decided to switch to PostgreSQL which solved the problem in first tests and hopefully keeps this good performance in other tests. But if you still want to know what I tried to explain in my last six messages: Accessing the database-view using a WHERE-condition is as slow as without and it takes 350 times more time to generate results instead of using the SQL which generated the view and put a WHERE-condition directly into it. Optimizing the view didn't solve the problem. The problem isn't the query (because with WHERE-conditions or a LIMIT it performed very well - and it was the usual case to use conditions or limits) but the view which was with and without conditions equally slow. So I decided to use Django: I couldn't generate the query using Django's ORM. So tried to put the SQL directly into Django without using the db.cursor() which wouldn't solve my problem because i couldn't use extra() anymore. It didn't work because of table-aliases I think, but I didn't do any further testing. But I'd recommend to extend the extra(tables=...)-method to accept own aliases for tables. Oh, I think at least this all wasn't really my problem. The problem is the way how the MySQL-guys have implemented views (http:// bugs.mysql.com/bug.php?id=23136). My attempt was just a workaround to solve this... So the idea behind my question was to implement some sort of database- view in django, so that you just take the sql which would create the view and put it into a model. Why? Because MySQL doesn't handle some views very well and maybe other DBMS also don't and you could make new models which could just join and aggregate data from other tables or... I don't know. hope that this isn't my problem 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: Rethinking silent failures in templates
Graham King wrote: > And if Django had logging, we could have a SQL log, and I wouldn't > have to start all my projects by setting up a logger, a SQL logging > middleware, and an audit log of object create/update/delete. I trust you've seen the django-logging project on c.g.c? http://code.google.com/p/django-logging/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
bug? Issue with markdown, encoding and mysql
I just ran into an issue where i was getting unicode errors when trying
to insert data into mysql (via a model).
I had this code:
--
from django.contrib.markup.templatetags.markup import markdown
def save(self):
self.content_html = markdown(self.content_source)
super(Chapter, self).save()
--
self.content_source is utf-8
This would cause a unicode error when the code tried to save the string
in the DB (mysql) if content_source contained any non-ascii chars.
I was able to fix this by explicitly setting the encoding on the string
returned from markdown()
--
from django.contrib.markup.templatetags.markup import markdown
def save(self):
self.content_html = markdown(self.content_source).encode("utf-8")
super(Chapter, self).save()
--
However, I would have expected the markdown function to return the
correctly encoded string.
Here is a simple script that I believe shows the difference in output:
--
from django.contrib.markup.templatetags.markup import markdown
tmp = u'Andr\202'
m = markdown(tmp)
print m
m = markdown(tmp).encode("utf-8")
print m
--
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
django.VERSION (0, 97, 'pre')
I am pretty new to django, and dont have much experience working with
unicode, so I wanted to post here to see if anyone thought that this
looked like a bug? If so I will log it.
mike
--~--~-~--~~~---~--~~
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: bug? Issue with markdown, encoding and mysql
This appears to be a usage question. This list is for the development
of Django itself, not developing projects that use Django. Usage
questions should be directed to the django-users list [1].
[1]: http://groups.google.com/group/django-users
That said, it appears that you are taking issue with markdown, which
is a separate library not included with django. Issues with markdown
should be addressed on that projects mailing list [2]. However, keep
in mind that markdown knows (almost) nothing about encodings. It only
works with unicode (or ascii) text. You *must* give markdown unicode
text and it *only* outputs unicode text. It is your responsibility to
deal with whatever encodings you need. It would be almost imposable
for markdown to support every possibility, so it doesn't even try.
[2]:
http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss
However, Django does have some handy mechanisms [3] for dealing with
this sort of thing. You might want to check them out.
[3]: http://www.djangoproject.com/documentation/unicode/
Also, why are you importing markdown from the template filter? Why not
just import markdown directly?
On Wed, May 21, 2008 at 2:11 PM, Mike Chambers <[EMAIL PROTECTED]> wrote:
>
> I just ran into an issue where i was getting unicode errors when trying
> to insert data into mysql (via a model).
>
> I had this code:
>
> --
> from django.contrib.markup.templatetags.markup import markdown
>
> def save(self):
>self.content_html = markdown(self.content_source)
>
>super(Chapter, self).save()
> --
>
> self.content_source is utf-8
>
> This would cause a unicode error when the code tried to save the string
> in the DB (mysql) if content_source contained any non-ascii chars.
>
> I was able to fix this by explicitly setting the encoding on the string
> returned from markdown()
>
> --
> from django.contrib.markup.templatetags.markup import markdown
>
> def save(self):
>self.content_html = markdown(self.content_source).encode("utf-8")
>
>super(Chapter, self).save()
> --
>
> However, I would have expected the markdown function to return the
> correctly encoded string.
>
> Here is a simple script that I believe shows the difference in output:
>
> --
> from django.contrib.markup.templatetags.markup import markdown
>
> tmp = u'Andr\202'
> m = markdown(tmp)
> print m
> m = markdown(tmp).encode("utf-8")
> print m
> --
>
> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
> django.VERSION (0, 97, 'pre')
>
> I am pretty new to django, and dont have much experience working with
> unicode, so I wanted to post here to see if anyone thought that this
> looked like a bug? If so I will log it.
>
> mike
>
>
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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: bug? Issue with markdown, encoding and mysql
On Wed, May 21, 2008 at 2:32 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: [snip] > in mind that markdown knows (almost) nothing about encodings. It only > works with unicode (or ascii) text. You *must* give markdown unicode > text and it *only* outputs unicode text. It is your responsibility to > deal with whatever encodings you need. It would be almost imposable > for markdown to support every possibility, so it doesn't even try. > Oh, I should mention that this policy has only been strictly enforced on the most recent release (1.7) of Python-Markdown. Previous versions may have appeared to work with some encodings, but it was always buggy. Your encouraged to upgrade to the latest version. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: bug? Issue with markdown, encoding and mysql
Sorry. I passed some UTF-8 text to the
django.contrib.markup.templatetags.markup.markdown function (which is
included with django), and got what appeared to be an incorrectly
encoded string in return.
I thought this MIGHT be a bug with the django markdown function. If it
was, then I would log it.
From what you suggested, it appears that it is a bug with the
underlying markdown library, and not the django markdown function.
Therefore, I won't log it.
I apologize for the noise this added to the list, and will be more
circumspect in the future when trying to contribute to improving django.
mike
Waylan Limberg wrote:
> This appears to be a usage question. This list is for the development
> of Django itself, not developing projects that use Django. Usage
> questions should be directed to the django-users list [1].
>
> [1]: http://groups.google.com/group/django-users
>
> That said, it appears that you are taking issue with markdown, which
> is a separate library not included with django. Issues with markdown
> should be addressed on that projects mailing list [2]. However, keep
> in mind that markdown knows (almost) nothing about encodings. It only
> works with unicode (or ascii) text. You *must* give markdown unicode
> text and it *only* outputs unicode text. It is your responsibility to
> deal with whatever encodings you need. It would be almost imposable
> for markdown to support every possibility, so it doesn't even try.
>
> [2]:
> http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss
>
> However, Django does have some handy mechanisms [3] for dealing with
> this sort of thing. You might want to check them out.
>
> [3]: http://www.djangoproject.com/documentation/unicode/
>
> Also, why are you importing markdown from the template filter? Why not
> just import markdown directly?
>
> On Wed, May 21, 2008 at 2:11 PM, Mike Chambers <[EMAIL PROTECTED]> wrote:
>> I just ran into an issue where i was getting unicode errors when trying
>> to insert data into mysql (via a model).
>>
>> I had this code:
>>
>> --
>> from django.contrib.markup.templatetags.markup import markdown
>>
>> def save(self):
>>self.content_html = markdown(self.content_source)
>>
>>super(Chapter, self).save()
>> --
>>
>> self.content_source is utf-8
>>
>> This would cause a unicode error when the code tried to save the string
>> in the DB (mysql) if content_source contained any non-ascii chars.
>>
>> I was able to fix this by explicitly setting the encoding on the string
>> returned from markdown()
>>
>> --
>> from django.contrib.markup.templatetags.markup import markdown
>>
>> def save(self):
>>self.content_html = markdown(self.content_source).encode("utf-8")
>>
>>super(Chapter, self).save()
>> --
>>
>> However, I would have expected the markdown function to return the
>> correctly encoded string.
>>
>> Here is a simple script that I believe shows the difference in output:
>>
>> --
>> from django.contrib.markup.templatetags.markup import markdown
>>
>> tmp = u'Andr\202'
>> m = markdown(tmp)
>> print m
>> m = markdown(tmp).encode("utf-8")
>> print m
>> --
>>
>> Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
>> django.VERSION (0, 97, 'pre')
>>
>> I am pretty new to django, and dont have much experience working with
>> unicode, so I wanted to post here to see if anyone thought that this
>> looked like a bug? If so I will log it.
>>
>> mike
>>
>>
>
>
>
--~--~-~--~~~---~--~~
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: document based database
that's exactly what I meant, thanks Daryl On May 20, 4:12 pm, "Daryl Spitzer" <[EMAIL PROTECTED]> wrote: > Perhaps bedros meant to ask if anyone is working on support in Django > for any "document based" databases. > > strokeDB looks (to my untrained eye) similar to CouchDB. You'll find > plenty to read if you do a search for "couchdb django". > > -- > Daryl > > On Tue, May 20, 2008 at 4:06 PM, Collin Grady <[EMAIL PROTECTED]> wrote: > > > bedros said the following: > >> are you guys aware of any document based database open source > >> implementation in Python such as strokeDB for Ruby > > > This question does not belong on this list - this list is for the > > discussion of > > the development of django itself, not for other questions. > > > -- > > Collin Grady > > > The nation that controls magnetism controls the universe. > >-- Chester Gould/Dick Tracy --~--~-~--~~~---~--~~ 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: bug? Issue with markdown, encoding and mysql
On Wed, May 21, 2008 at 2:57 PM, Mike Chambers <[EMAIL PROTECTED]> wrote: > > Sorry. I passed some UTF-8 text to the > django.contrib.markup.templatetags.markup.markdown function (which is > included with django), and got what appeared to be an incorrectly > encoded string in return. Ah, OK, I guess you were trying to use django's wrapper to deal with encoding. Personally, I find that a little strange as it's meant specifically for the template system, but anyway... Django passes text around as unicode and I believe the wrapper function expects unicode as well. That's the thing, by the time text reaches the template, it's expected to already be unicode. As your trying to use the filter in an unintended fashion, you would need to convert your UTF-8 text to unicode first - or at least tell django that you have UTF-8 text. It's usually easier to convert to unicode. See the unicode documentation I linked to in my previous response. Of course, if you have to do that, you might as well use markdown directly. > > I thought this MIGHT be a bug with the django markdown function. If it > was, then I would log it. The "MIGHT" is your clue. If your not sure you have a bug, it's always best to assume user error. If a discussion on the users list confirms a bug exists, then it's time to report a bug and/or discuss ways to fix the bug in the dev list. > > From what you suggested, it appears that it is a bug with the > underlying markdown library, and not the django markdown function. > Therefore, I won't log it. > > I apologize for the noise this added to the list, and will be more > circumspect in the future when trying to contribute to improving django. No apology needed. Its an easy mistake for newer users to make. Now that you've been filled in on the details, you'll know how to proceed next time. Don't ever hesitate to contribute to Django. -- Waylan Limberg [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Multiple database support
Hi guys -- Sorry for coming late to the party, but I'm just now catching up on django-dev. I'm really glad to see you get the ball rolling on multiple db support, and once I'm dug out from my backlog I'll be happy to start reviewing code and helping out if I'm needed. However, before we get to that point, I've got some pretty serious API concerns with the current approach, so I think I should outline those before y'all go much further. I don't want you to expend much effort just to get a -1 smackdown. The current mechanism of defining "other" databases in the settings module is just fine, and the underlying mechanism of having queries/managers "know" their connection is similarly dandy. But the wheels come off when it comes to the "public" API where users will choose which connection they use. As far as I can tell, you've currently provided two hooks to use a secondary connection: set the model's default connection in the settings module (which is OK, I suppose, though I might want to nitpick the syntax a bit), and assigning to ``Model.objects.db``. This second one is a disaster waiting to happen -- you've had to muddy things up with threadlocals to work around some problems already. Also consider the "bookkeeping" you'd need to do to deal with objects across multiple database simultaneously (think sharding). You'd have to keep juggling ``Model.objects.db`` and saving old ones... ugh. Here's how I think it should work: * I'd like the default connection for each and every object to be the default database forever and always. I find putting models for default connections in settings distasteful and I'd rather just a single API for changing the connection (see below). However, I imagine I'll be in the minority here so I'm prepared to cede this point if necessary. * There needs to be an official API to get a model (or perhaps a manager) which references a different "context" -- ``Model.objects.db`` should be read-only. So you'd call some API method, and get back a sort of proxy object that uses the other connection. Here's a strawman API:: >>> from django import db >>> from someapp.models import Article >>> Article.objects.all() [... all Articles from the default database ...] >>> ArticlesOnOtherDatabase = db.get_model_for_other_connection(Article, "private") >>> ArticlesOnOtherDatabase.objects.all() [... all Articles from the database defined with the "private" key ...] This should make the threadlocal stuff unnecessary, and (to my eye) is a lot more sane than assigning the ``Manager.db``. Oh, and please choose a better better name than ``db.get_model_for_other_connection()``; given that you're building the bikeshed you might as well paint it, too. Jacob --~--~-~--~~~---~--~~ 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: Multiple database support
Hi Jacob, I'd be interested in your thoughts on a declarative approach to defining the other databases...? I'll have my mercurial repo synced up to trunk tomorrow (my time) and I'll re-apply the patch I got from Daryl to it as a starting point. Hopefully people will be able to have a look through it and compare the declarative approach proposed with the existing multi-db approach. As far as I can tell, you've currently provided two hooks to use a > secondary connection: set the model's default connection in the > settings module (which is OK, I suppose, though I might want to > nitpick the syntax a bit), and assigning to ``Model.objects.db``. > > This second one is a disaster waiting to happen -- you've had to muddy > things up with threadlocals to work around some problems already. Also > consider the "bookkeeping" you'd need to do to deal with objects > across multiple database simultaneously (think sharding). You'd have > to keep juggling ``Model.objects.db`` and saving old ones... ugh. I built a non trivial application with multi-db as it is right now and found the api to be a bit hairy to be honest. I think it would be an advantage, especially in a "database rich" environment to be able to build a db on the fly much like a model, rather than be tied to what's in a dict in settings. I don't really like the objects.db way of doing it, and I found myself doing a fair bit of hacking to get it to work. > * There needs to be an official API to get a model (or perhaps a > manager) which references a different "context" -- > ``Model.objects.db`` should be read-only. So you'd call some API > method, and get back a sort of proxy object that uses the other > connection. Here's a strawman API:: > > >>> from django import db > >>> from someapp.models import Article > > >>> Article.objects.all() > [... all Articles from the default database ...] > > >>> ArticlesOnOtherDatabase = db.get_model_for_other_connection(Article, "private") > >>> ArticlesOnOtherDatabase.objects.all() > [... all Articles from the database defined with the "private" key ...] Agreed, the way I got round this was to build the model again from scratch each time I wanted to access objects in a different database and have the dynamicaly created model persist in the app cache. I took most of this from the dynamic models entry on the wiki, it's here, look in the duplicate_model function: http://www.djangosnippets.org/snippets/442/ This would really need work (especially the field copying code, which is fairly horrifying! I know that doesn't work for all field types too - yuk) before it becomes a 'good idea', and I'm not even sure it's the right way to go, however I'd be interested in weather people think it's a valid approach. * I'd like the default connection for each and every object to be the > default database forever and always. I find putting models for default > connections in settings distasteful and I'd rather just a single API > for changing the connection (see below). However, I imagine I'll be in > the minority here so I'm prepared to cede this point if necessary. The API which I think is being proposed is that there should be a central register for database connections. In my mind this would be the place to go to get hold of a connection for use in a queryset (and all the other places it's needed) and I think the correct default behaviour of the class/object would be to return the connection defined in settings.DATABASE_*. The code to build the declarative DatabaseWrapper is already there, and there a method to build one of these from what's in settings too. This should make it easy to get hold of connection in all of the places where we currently do "from django.db import connection". It's great to see this revived again :-) Cheers Ben -- Regards, Ben Ford [EMAIL PROTECTED] +447792598685 --~--~-~--~~~---~--~~ 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: Multiple database support
On May 21, 2:16 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > * There needs to be an official API to get a model (or perhaps a > manager) which references a different "context" -- > ``Model.objects.db`` should be read-only. So you'd call some API > method, and get back a sort of proxy object that uses the other > connection. Here's a strawman API:: > > >>> from django import db > >>> from someapp.models import Article > > >>> Article.objects.all() > [... all Articles from the default database ...] > > >>> ArticlesOnOtherDatabase = > db.get_model_for_other_connection(Article, "private") > >>> ArticlesOnOtherDatabase.objects.all() > [... all Articles from the database defined with the "private" key ...] > Has anybody considered declaring the connection when getting the manager? Something like: Artist.objects.all() Widget.objects(db='a').all() Obviously with the default database for the case when "db" isn't passed. Also you could override the Manager to use a different database by default (e.g. Widget.objects.all() might always use an OTHER_DATABASE while all other models use the main db, if you create a custom Manager for Widget) This still leaves questions about how syncdb would be achieved, at least. But if it could be done, the API seems simple to understand. -rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Bug (very mild) in PostgreSQL version _check_
Dear all, I think I've found a bug in Django and a solution :-) In django/db/backends/postgresql/operations.py (svn) there is a PostgreSQL version check that reads like this: if self.postgres_version[0] >= 8 and self.postgres_version[1] >= 1 Bug: When PostgreSQL turns 9.0 (a year from now? ), the test will yield False, since self.postgres_version[1] will hold 0. Solution: Use Python's great sequence comparison syntax, something like: if self.postgres_version[:] >= (8,1): Thought about writing a function that specializes in checking versions, but didn't find any additional value as the latter proposal. I also looked for more uses of the string "postgres_version" in Django source code, but besides the aforementioned, the only use is the loading of postgres_version sequence itself, which does it job nicely. Hope some developer finds this contribution useful, since I'm new here but am trying hard to learn, and eventually, be able to contribute to this Great project that Django is. My $0.02.- Best regards to all Haroldo.- --~--~-~--~~~---~--~~ 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: Multiple database support
I really like this line of thought: having the persistence layer of a model fixed is a good idea. Relations is a big issue here: unless we can support relations across databases, switching connections is always a big opportunity to shoot yourself in the foot. I would propose a function that can collect "clusters" of models, that is a collection of models that somehow are related to each other and use that function to a) check that they all use the same database during validation, and b) if we provide a API to register a model for an additional connection (that is a second one), you get copies of the models for the entire cluster, relations and all. Like that we could even have syncdb create the tables for these 'backup models' too. Koen On 21 mei, 23:16, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hi guys -- > > Sorry for coming late to the party, but I'm just now catching up on > django-dev. > > I'm really glad to see you get the ball rolling on multiple db > support, and once I'm dug out from my backlog I'll be happy to start > reviewing code and helping out if I'm needed. > > However, before we get to that point, I've got some pretty serious API > concerns with the current approach, so I think I should outline those > before y'all go much further. I don't want you to expend much effort > just to get a -1 smackdown. > > The current mechanism of defining "other" databases in the settings > module is just fine, and the underlying mechanism of having > queries/managers "know" their connection is similarly dandy. But the > wheels come off when it comes to the "public" API where users will > choose which connection they use. > > As far as I can tell, you've currently provided two hooks to use a > secondary connection: set the model's default connection in the > settings module (which is OK, I suppose, though I might want to > nitpick the syntax a bit), and assigning to ``Model.objects.db``. > > This second one is a disaster waiting to happen -- you've had to muddy > things up with threadlocals to work around some problems already. Also > consider the "bookkeeping" you'd need to do to deal with objects > across multiple database simultaneously (think sharding). You'd have > to keep juggling ``Model.objects.db`` and saving old ones... ugh. > > Here's how I think it should work: > > * I'd like the default connection for each and every object to be the > default database forever and always. I find putting models for default > connections in settings distasteful and I'd rather just a single API > for changing the connection (see below). However, I imagine I'll be in > the minority here so I'm prepared to cede this point if necessary. > > * There needs to be an official API to get a model (or perhaps a > manager) which references a different "context" -- > ``Model.objects.db`` should be read-only. So you'd call some API > method, and get back a sort of proxy object that uses the other > connection. Here's a strawman API:: > > >>> from django import db > >>> from someapp.models import Article > > >>> Article.objects.all() > [... all Articles from the default database ...] > > >>> ArticlesOnOtherDatabase = > db.get_model_for_other_connection(Article, "private") > >>> ArticlesOnOtherDatabase.objects.all() > [... all Articles from the database defined with the "private" key ...] > > This should make the threadlocal stuff unnecessary, and (to my eye) is > a lot more sane than assigning the ``Manager.db``. Oh, and please > choose a better better name than > ``db.get_model_for_other_connection()``; given that you're building > the bikeshed you might as well paint it, too. > > Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
