Re: Would a web search be a good addition to the contribs framework?
Matt Davies wrote: > yes please shabda > > we're currenlty moving away from webglimpse and into solr for our > search engine technology, but something inside django itself would be > really useful. > > While I live and breathe solr (we use it VERY heavily @ $WORK), I'm not sure what you would be adding that the solr python client API doesn't give you. I would recommend using https://issues.apache.org/jira/browse/SOLR-216 it's pretty simple to use. BTW, this is different to what shabda was proposing, which was doing all-the-web type searches regards Ian > Especially if you could query other django appilcations from within > one application. > > ooh, now dat be tasty burgers > > On 01/10/2007, shabda.raaj <[EMAIL PROTECTED]> wrote: > >> It looks to me that a api to get web search functionality in Django >> would be good idea. For example, I generally want to keep track of the >> pages linking to my sites. Similarly being able to search from inside >> of django might be useful in many cases. >> Would a web search be a good addition to the contribs framework? I am >> willing to code this. But before doing that, I just want to make sure >> it would be useful to people :) >> (I just plan to add convinient api for webservices found at >> http://developer.yahoo.com/search/ ) >> >> >> > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
MANAGEMENT SOLUTIONS
*Management is the key to success.* *http://www.100stuff.com/sdk/management/* *-* --~--~-~--~~~---~--~~ 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: Django External Schema Evolution Branch (deseb)
hey nis,
1) psycopg2 has been added as a backend
2-4) the other three bugs i've verified and fixed in svn. (plus i've
started a new "everything" test case to check all the field types from
now on)
> I think the introspection code for postgres can be tightened a lot -
> especially if we limit ourselves to versions >=7.4 - I am happy to help
> in this area.
i'll take any suggestions you have. :)
thanks,
derek
Nis Jørgensen wrote:
> Derek Anderson skrev:
>> Django External Schema Evolution Branch
>> ===
>> http://code.google.com/p/deseb/
>>
>> I've released v0.2, which supports both MySQL and Postgresql, and works
>> with both django-head and django-v0.96.
>>
>> This release contains the introspection/generation code only. The
>> "schema signing/fingerprinting" and "managed schema updates" have yet to
>> be ported.
>>
>> Installation is dead simple. Download and extract it into your
>> site-packages dir, and add "import deseb" to settings.py.
>>
>> If you have an interest, please give it a whirl and send me feedback.
>> (either privately or here, I don't care) But please, restrain from
>> publicly flogging it/me until AFTER you've actually used it. =p
>>
> I am now running into my fourth problem needing fixing before I can
> "actually use it". I have no more time for this now - but I am happy to
> help later.
>
> First problem:
>
> psycopg2 is not supported
>
> First fix:
>
> --- deseb/schema_evolution.py 2007-09-30 21:06:17.0 +
> +++ /usr/lib/python2.4/site-packages/deseb/schema_evolution.py
> 2007-10-02 08:08:00.0 +
> @@ -29,8 +29,10 @@
>
> backend_type = str(connection.__class__).split('.')[3]
> if backend_type=='mysql': import deseb.backends.mysql as backend
> -if backend_type=='postgresql': import deseb.backends.postgresql as
> backend
> -if backend_type=='sqlite3': import deseb.backends.sqlite3 as backend
> +elif backend_type in ['postgresql', 'postgresql_psycopg2']: import
> deseb.backends.postgresql as backend
> +elif backend_type=='sqlite3': import deseb.backends.sqlite3 as backend
> +else:
> + raise Exception('Backend not supported') # This should raise a
> more relevant exception
> ops = backend.DatabaseOperations(connection, style)
> introspection = backend.DatabaseIntrospection(connection)
> return ops, introspection
>
> Second problem:
> Unknown function ops.quote_name
>
> Second fix:
>
> (this may not be how it was intended to work)
>
> --- deseb/schema_evolution.py 2007-09-30 21:06:17.0 +
> +++ /usr/lib/python2.4/site-packages/deseb/schema_evolution.py
> 2007-10-02 08:08:00.0 +
> @@ -409,8 +411,8 @@
> if f.rel:
> if f.rel.to in known_models:
> field_output.append(style.SQL_KEYWORD('REFERENCES') + '
> ' + \
> -
> style.SQL_TABLE(ops.quote_name(f.rel.to._meta.db_table)) + ' (' + \
> -
> style.SQL_FIELD(ops.quote_name(f.rel.to._meta.get_field(f.rel.field_name).column))
> + ')' #+
> +
> style.SQL_TABLE(connection.ops.quote_name(f.rel.to._meta.db_table)) + '
> (' + \
> +
> style.SQL_FIELD(connection.ops.quote_name(f.rel.to._meta.get_field(f.rel.field_name).column))
> + ')' #+
> #backend.get_deferrable_sql()
> )
> else:
>
> Third problem:
>
> Default values are not always strings:
>
> File "/usr/lib/python2.4/site-packages/deseb/backends/postgresql.py",
> line 126, in get_known_column_flags
> dict['default'] = row[1][1:row[1].index("'",1)]
> ValueError: substring not found
>
> Fix:
>
> (more problems are likely to exist for other data types - but at least I
> get past the error)
>
> Only in /usr/lib/python2.4/site-packages/deseb/backends: __init__.pyc
> diff -u -r deseb/backends/postgresql.py
> /usr/lib/python2.4/site-packages/deseb/backends/postgresql.py
> --- deseb/backends/postgresql.py2007-09-30 02:28:43.0 +
> +++ /usr/lib/python2.4/site-packages/deseb/backends/postgresql.py
> 2007-10-02 08:28:06.0 +
> @@ -122,7 +122,10 @@
> for row in cursor.fetchall():
> if row[0] == column_name:
> if row[1][0:7] == 'nextval': continue
> -dict['default'] = row[1][1:row[1].index("'",1)]
> + if row[1][0] == "'":
> + dict['default'] = row[1][1:row[1].index("'",1)]
> + else:
> + dict['default'] = row[1]
>
> #print table_name, column_name, dict
> return dict
>
>
>
> Fourth problem:
>
> File "/usr/lib/python2.4/site-packages/deseb/schema_evolution.py", line
> 210, in get_sql_evolution_check_for_dead_fields
> suspect_fields.discard(f.aka)
> AttributeError: 'TextField' object has no attribute 'aka'
>
> Fix:
>
> ???
>
> I think the introspection code for postgres can be tightened a
Re: Possible bug in Meta ordering in 0.96
As James says, it's not a bug. But I'd agree it seems a little odd, until you look a little more closely at the admin interface. It allows the user to sort on fields by clicking on column headers. It gets a little messy to try to combine that feature with multi-field ordering specified in the model, so I'd guess that is why the admin interface only ever pays attention to the first field listed in "ordering". That's just my guess though. Karen --~--~-~--~~~---~--~~ 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: Regression tests for localflavor
On Tue, 2007-10-02 at 11:08 -0700, Marc Garcia wrote: > Hi! > > I know that it's probably a newbie question, but I'm not sure how I've > to make regression tests to a new localflavor that I've developed. > > I've seen that there is a test file for every localflavor in .../trunk/ > tests/regressiontests/forms/localflavor/ but I'm not sure if that file > is generated through any script, or is a standard set of tests, or > it's just a custom testing that I've to decide? You get to decide which things to test. That file is manually generated, so just add any extra things you want using a similar style (add a comment before your section saying which localflavor it is testing, etc). Generally, try to write tests for good, bad and missing data for any new classes you are creating. > > Also, I've seen that there is another test file where all those > localflavor files are imported, I figure out that I've to add mine, > but Do I have to execute it later? Why? The "controlling" file for that particular set of tests is regressiontests/forms/tests.py (look for the __tests__ dictionary). However, you don't need to do anything special beyond adding new lines to the localflavor.py file. The main runtests.py script will import forms/tests.py, which will import forms/localflavor.py and run all the doctests. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Regression tests for localflavor
Hi! I know that it's probably a newbie question, but I'm not sure how I've to make regression tests to a new localflavor that I've developed. I've seen that there is a test file for every localflavor in .../trunk/ tests/regressiontests/forms/localflavor/ but I'm not sure if that file is generated through any script, or is a standard set of tests, or it's just a custom testing that I've to decide? Also, I've seen that there is another test file where all those localflavor files are imported, I figure out that I've to add mine, but Do I have to execute it later? Why? Thanks! Marc --~--~-~--~~~---~--~~ 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: Possible bug in Meta ordering in 0.96
On 10/2/07, Xan <[EMAIL PROTECTED]> wrote: > I know that this behaviour is documented, but is it a bug so?. The > strange behaviour of admin, even altough it's documented, is strange. > Why you don't consider it a bug? Is there a ticket of that? Do you > plan to change this (strange) behaviour in next version (svn)? If not, > why? A "bug" is when software does not behave the way it is supposed to. The software is supposed to behave this way. Therefore, this is not a bug. If you think that it would be a good *enhancement* to add support for multi-column ordering, that's another issue entirely, but software behaving as document is not and can not be a "bug". -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Possible bug in Meta ordering in 0.96
Yes. I understand it.
I know that this behaviour is documented, but is it a bug so?. The
strange behaviour of admin, even altough it's documented, is strange.
Why you don't consider it a bug? Is there a ticket of that? Do you
plan to change this (strange) behaviour in next version (svn)? If not,
why?
Thanks,
Xan.
On Oct 2, 9:39 am, Michael Radziej <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 01, Xan wrote:
>
> > On Sep 30, 11:22 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > > On 9/30/07, Xan <[EMAIL PROTECTED]> wrote:
>
> > > > Although ordering is ('tipus', 'nom'), django admin interface displays
> > > > the Centre objects by 'tipus' but randomly (?) with 'nom'. I don't
> > > > know how can I do, because, in shell when I put
> > > > > Centre.objects.order_by('tipus', 'nom')
>
> > > Please read the Django documentation:
>
> > >http://www.djangoproject.com/documentation/model-api/#ordering
>
> > > > So, is it possible bug in 0.96?
>
> > > No, read the documentation and it will tell you exactly what you're
> > > seeing.
>
> > Oh! yes.
>
> > But, is it a bug so?
>
> If it is in the documentation, it is intended behaviour.
>
> Please, direct questions about the useage of Django to django-users, and not
> django-developers, which is for developing the Django framework itself. And
> that does include bugs unless you're pretty sure that this is a core issue
> for Django developers. Which is extremely seldom the case.
>
> Michael
>
> --
> noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
> Tel +49-911-9352-0 - Fax +49-911-9352-100http://www.noris.de- The
> IT-Outsourcing Company
>
> Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
> Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
--~--~-~--~~~---~--~~
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: Displaying current file in admin for a filefield
Apologies. Meant to post that to Django-Users (although I've probably got a better chance of a useful answer here I am aware that it's not really the right question for this group). However now it's here - any tips gratefully received! On Oct 2, 2:22 pm, andybak <[EMAIL PROTECTED]> wrote: > Hi there, > > I'm looking to figure out how to subclass the widget for the FileField > in newforms-admin so that it displays the current filename next to the > upload field. > > Does anyone know there are any examples/resources to help me get > started? I assume I need to subclass forms.widgets.Widget and override > the render method at the very least. > > thanks in advance, > > Andy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Displaying current file in admin for a filefield
Hi there, I'm looking to figure out how to subclass the widget for the FileField in newforms-admin so that it displays the current filename next to the upload field. Does anyone know there are any examples/resources to help me get started? I assume I need to subclass forms.widgets.Widget and override the render method at the very least. thanks in advance, Andy --~--~-~--~~~---~--~~ 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: Another urlpatterns proposal (add method column)
On 10/2/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > That said, I think there are probably others out there like you who > would want this, and there's actually nothing stopping you from > releasing it as a separate app, or even a snippet. Well, looks like I misspoke. It seems the URL resolver is only given the path, as opposed to the whole request object, so it would require a bit more hacking than I originally thought. It might still be possible without changing any Django internals, but you'd have to touch more than you should, and it wouldn't be pretty. I wouldn't recommend it, so consider that whole idea withdrawn. Sorry about not looking at the code before I typed. -Gul --~--~-~--~~~---~--~~ 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: Another urlpatterns proposal (add method column)
I can't say I'm a big fan of this proposal, personally. While I can understand where you're coming from, it smells a bit too much like J2EE's doGet/doPost stuff for my taste. On a more objective note, though, would that mean that every urlpattern would require an HTTP method, or could it be ignored (with GET presumably implied)? If it can be ignored, how would the resolver tell the difference between an HTTP method string and a URL regex string? (I think I have an answer for this, but it's worth asking anyway.) And if the method is in fact required in all cases, I think this would add way too much added complexity for the common case. Most people only use GET and POST, and most of their URLs are going to be GET only. On top of that, I expect most GET/POST views are forms, where it would make sense to share logic for form generation, template selection, etc. Expecting people to separate those into two separate views seems unnecessarily complex. And yes, I do realize that your constants proposal does alleviate some of these problems. For instance, you mention having HTTP_ALL, which, if used as a default, would provide existing functionality without change. Also, by using constants, the values could be numbers, which could then be OR'd together (ie, HTTP_GET | HTTP_POST), and this would also provide a means of differentiating between the required HTTP method(s) and the regex string. These things do help somewhat, but they add a great deal of complexity where I don't think it's merited. That said, I think there are probably others out there like you who would want this, and there's actually nothing stopping you from releasing it as a separate app, or even a snippet. Essentially, you'd just write a replacement for the existing url resolvers, probably subclassing the existing ones to minimize new code. Then in your urls.py, you import your own rather than the Django ones. If nothing else, this would give the core developers proof of what you're talking about, it would give other developers a chance to try it out and see if they like it any better, it would give you some valuable feedback on the proposal in case it needs tweaking, and it would give you a chance to get your feet wet on hacking a bit on things related to Django internals. If you'd like to go that route, let me know and I'd be willing to help you out with it. -Gul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Another urlpatterns proposal (add method column)
IMHO, we should move typical logic of switching actual view according
to request HTTP method from views to urls.py. Dispatching URLs using
info from request is a job for urls.py, not for views itself.
I think following code is inefficient and does the same as urls.py
does with URL of requests:
# urls.py
urlpatterns = patterns('',
(r'^goods/', 'mysite.goods.views.goods'),
)
# views.py
def goods(request):
if request.method == 'GET':
return goods_show(request)
elif request.method == 'PUT':
return goods_create(request)
elif request.method == 'POST'
return goods_update(request)
elif request.method == 'DELETE':
return goods_delete(request)
We can just add a method filter like we do with request URL. Then
urls.py will look something like that:
urlpatterns = patterns('',
('*', r'^django/admin/', include('django.contrib.admin.urls')),
('GET', r'^django/polls/(?P\d+)/', 'mysite.polls.views.show'),
('PUT', r'^django/polls/', 'mysite.polls.views.create'),
('POST', r'^django/polls/(?P\d+)/',
'mysite.polls.views.update'),
('DELETE', r'^django/polls/(?P\d+)/',
'mysite.polls.views.delete'),
('GET,POST,PUT', r'^django/goods/view/(?P\d+)',
'mysite.goods.views.show'), # don't care of method except DELETE
)
If method + URL did not match current request, then Django should
raise Http404 error - like file is not found.
I it's clear, simple as possible and highly configurable. Also, we
have no magic here (no HTTP_method_name <-> view_method_name
dependencies).
You can always move method distinction to other file to keep urls.py
definitely clear:
urlpatterns = patterns('',
('*', r'^django/goods/', include('mysite.goods.urls')),
)
P.S. We can move methods into constants like that:
from django.http.methods import *
urlpatterns = patterns('',
(HTTP_ALL, r'^django/admin/',
include('django.contrib.admin.urls')),
(HTTP_GET, r'^django/polls/(?P\d+)/',
'mysite.polls.views.show'),
)
That makes it even easier.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
FileField and semi-colon
Dear All,
Django can't handle file file ';' in filename correctly. In
django/http/__init__.py function parse_file_upload (trunk)
def parse_file_upload(header_dict, post_data):
> "Returns a tuple of (POST QueryDict, FILES MultiValueDict)"
> import email, email.Message
> from cgi import parse_header
> raw_message = '\r\n'.join(['%s:%s' % pair for pair in
> header_dict.items()])
> raw_message += '\r\n\r\n' + post_data
> msg = email.message_from_string(raw_message)
> POST = QueryDict('', mutable=True)
> FILES = MultiValueDict()
> for submessage in msg.get_payload():
> if submessage and isinstance(submessage, email.Message.Message):
> name_dict = parse_header(submessage['Content-Disposition'])[1]
it import parse_header from cgi module (example from python-2.5):
> def parse_header(line):
> """Parse a Content-type like header.
>
> Return the main content-type and a dictionary of options.
>
> """
> plist = [x.strip() for x in line.split(';')]
> key = plist.pop(0).lower()
> pdict = {}
> for p in plist:
> i = p.find('=')
> if i >= 0:
> name = p[:i].strip().lower()
> value = p[i+1:].strip()
> if len(value) >= 2 and value[0] == value[-1] == '"':
> value = value[1:-1]
> value = value.replace('', '\\').replace('\\"', '"')
> pdict[name] = value
> return key, pdict
This function implicitly split ';' which will not work correctly for
filename that has ';' as part of its name.
Does the browser should escape ';' in filename before upload or we should do
it at application level or framework level or I should report this bug to
python mainstream?
Regards,
Chaiwat.S
--~--~-~--~~~---~--~~
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: Django External Schema Evolution Branch (deseb)
Derek Anderson skrev:
> Django External Schema Evolution Branch
> ===
> http://code.google.com/p/deseb/
>
> I've released v0.2, which supports both MySQL and Postgresql, and works
> with both django-head and django-v0.96.
>
> This release contains the introspection/generation code only. The
> "schema signing/fingerprinting" and "managed schema updates" have yet to
> be ported.
>
> Installation is dead simple. Download and extract it into your
> site-packages dir, and add "import deseb" to settings.py.
>
> If you have an interest, please give it a whirl and send me feedback.
> (either privately or here, I don't care) But please, restrain from
> publicly flogging it/me until AFTER you've actually used it. =p
>
I am now running into my fourth problem needing fixing before I can
"actually use it". I have no more time for this now - but I am happy to
help later.
First problem:
psycopg2 is not supported
First fix:
--- deseb/schema_evolution.py 2007-09-30 21:06:17.0 +
+++ /usr/lib/python2.4/site-packages/deseb/schema_evolution.py
2007-10-02 08:08:00.0 +
@@ -29,8 +29,10 @@
backend_type = str(connection.__class__).split('.')[3]
if backend_type=='mysql': import deseb.backends.mysql as backend
-if backend_type=='postgresql': import deseb.backends.postgresql as
backend
-if backend_type=='sqlite3': import deseb.backends.sqlite3 as backend
+elif backend_type in ['postgresql', 'postgresql_psycopg2']: import
deseb.backends.postgresql as backend
+elif backend_type=='sqlite3': import deseb.backends.sqlite3 as backend
+else:
+ raise Exception('Backend not supported') # This should raise a
more relevant exception
ops = backend.DatabaseOperations(connection, style)
introspection = backend.DatabaseIntrospection(connection)
return ops, introspection
Second problem:
Unknown function ops.quote_name
Second fix:
(this may not be how it was intended to work)
--- deseb/schema_evolution.py 2007-09-30 21:06:17.0 +
+++ /usr/lib/python2.4/site-packages/deseb/schema_evolution.py
2007-10-02 08:08:00.0 +
@@ -409,8 +411,8 @@
if f.rel:
if f.rel.to in known_models:
field_output.append(style.SQL_KEYWORD('REFERENCES') + '
' + \
-
style.SQL_TABLE(ops.quote_name(f.rel.to._meta.db_table)) + ' (' + \
-
style.SQL_FIELD(ops.quote_name(f.rel.to._meta.get_field(f.rel.field_name).column))
+ ')' #+
+
style.SQL_TABLE(connection.ops.quote_name(f.rel.to._meta.db_table)) + '
(' + \
+
style.SQL_FIELD(connection.ops.quote_name(f.rel.to._meta.get_field(f.rel.field_name).column))
+ ')' #+
#backend.get_deferrable_sql()
)
else:
Third problem:
Default values are not always strings:
File "/usr/lib/python2.4/site-packages/deseb/backends/postgresql.py",
line 126, in get_known_column_flags
dict['default'] = row[1][1:row[1].index("'",1)]
ValueError: substring not found
Fix:
(more problems are likely to exist for other data types - but at least I
get past the error)
Only in /usr/lib/python2.4/site-packages/deseb/backends: __init__.pyc
diff -u -r deseb/backends/postgresql.py
/usr/lib/python2.4/site-packages/deseb/backends/postgresql.py
--- deseb/backends/postgresql.py2007-09-30 02:28:43.0 +
+++ /usr/lib/python2.4/site-packages/deseb/backends/postgresql.py
2007-10-02 08:28:06.0 +
@@ -122,7 +122,10 @@
for row in cursor.fetchall():
if row[0] == column_name:
if row[1][0:7] == 'nextval': continue
-dict['default'] = row[1][1:row[1].index("'",1)]
+ if row[1][0] == "'":
+ dict['default'] = row[1][1:row[1].index("'",1)]
+ else:
+ dict['default'] = row[1]
#print table_name, column_name, dict
return dict
Fourth problem:
File "/usr/lib/python2.4/site-packages/deseb/schema_evolution.py", line
210, in get_sql_evolution_check_for_dead_fields
suspect_fields.discard(f.aka)
AttributeError: 'TextField' object has no attribute 'aka'
Fix:
???
I think the introspection code for postgres can be tightened a lot -
especially if we limit ourselves to versions >=7.4 - I am happy to help
in this area.
Nis
--~--~-~--~~~---~--~~
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: Would a web search be a good addition to the contribs framework?
On Oct 2, 12:30 am, "shabda.raaj" <[EMAIL PROTECTED]> wrote: > It looks to me that a api to get web search functionality in Django > would be good idea. Yes, a full-text search functionality is really cool and there has been considerable effort that has been put into this. Check out http://code.google.com/p/django-sphinx/ http://code.djangoproject.com/wiki/searchengine http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer > (I just plan to add convinient api for webservices found at > http://developer.yahoo.com/search/ ) Django has been a neutral web-framework without showing bias to any database, external apps etc. To use the Yahoo Web API's and then incorporate them as contrib apps would not be recommended. I would agree with Russell Keith-Magee on Django's philosophy to accept contrib apps. Cheers Thejaswi Puthraya --~--~-~--~~~---~--~~ 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: Possible bug in Meta ordering in 0.96
On Mon, Oct 01, Xan wrote:
>
>
>
> On Sep 30, 11:22 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > On 9/30/07, Xan <[EMAIL PROTECTED]> wrote:
> >
> > > Although ordering is ('tipus', 'nom'), django admin interface displays
> > > the Centre objects by 'tipus' but randomly (?) with 'nom'. I don't
> > > know how can I do, because, in shell when I put
> > > > Centre.objects.order_by('tipus', 'nom')
> >
> > Please read the Django documentation:
> >
> > http://www.djangoproject.com/documentation/model-api/#ordering
> >
> > > So, is it possible bug in 0.96?
> >
> > No, read the documentation and it will tell you exactly what you're seeing.
>
> Oh! yes.
>
> But, is it a bug so?
If it is in the documentation, it is intended behaviour.
Please, direct questions about the useage of Django to django-users, and not
django-developers, which is for developing the Django framework itself. And
that does include bugs unless you're pretty sure that this is a core issue
for Django developers. Which is extremely seldom the case.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
