> My initial thought is that, since this is going to require JavaScript,
> it's something to be implemented on a per-case basis using the admin
> JS option;
I am not familiar with this option you speak of. Do you have a link to
more information?
--~--~-~--~~~---~--~-
I'll describe what I think is an unaddressed area. I may be
misinformed. Everyone seems to have different ways of talking about
this type of situation. The solution may be a new feature or simply a
design pattern. There may already be a technique I am unaware of...
Consider an application with mo
> functionality in django.utils.dateformat introduces some other
Well, consider that under-documented. It's not clear how to do that as
a filter in the Template Guide.
I'll agree that it's outside the scope of 'humanize'.
--~--~-~--~~~---~--~~
You received this
The humanize middleware should probably handle pretty-printing dates as
well. It should also reflect I18N, if possible. I started a thread in
that group regarding this.
http://groups.google.com/group/Django-I18N/browse_thread/thread/f33c087fc57fb2bc
Are there any opinions about how to best abstr
> They should be added, since we are bound to get some edge cases wrong
> (c.f. initial SQL parsing) and having regression tests will help there.
> If you could add those, that would be great. Testing both sorts of
> quotes, backslashes, semicolons and percentage signs would be my
> suggestion for
ps.google.com/group/django-developers/browse_thread/thread/741ac793a9bf8459/d9bf516943a2e997?q=jws&rnum=1#d9bf516943a2e997
Jacob gave no reason for the second closure. I presume he was just
weeding patches with no activity.
> (3) The patch still needs some work. There is neither documentatio
I submitted a patch to the tracker some time ago that was never merged.
I'm unsure if there's some other community protocol for getting things
accepted that I need to follow.
I've described the problem, submitted a complete, working patch, got
buy-in from Adrian in principle, and had at least one
As previously discussed in the thread below, we had rough consensus
that it would be good for default values in models to be part of the
sql generated when installing apps. I have updated my patch and
reopened the original ticket. Is this acceptable to merge?
Discussion:
http://groups.google.com/
If this sounds reasonable, I'll attach my diff to the original ticket,
re-open it and continue the discussion there.
OK, so this is not a problem when we are working with the databases
'live', since they are using parameterized queries. It IS a problem
when using the 'install' and 'sql' sub-commands, since those are built
up using simple string concatenation.
So if all the following were true, would this be acc
My ticket was closed - http://code.djangoproject.com/ticket/470
I'd like to clarify the reasoning, since I think it pertains to a
larger issue. My understanding of Adrian's comment is that there
currently is no infrastructure in Django to escape special characters
in strings in a way that is spec
I'd like to hear some discussion regarding what seems to be a common
situation and how to best address it within Django-powered sites.
Frequently there will be hierarchical data stored in the db as tables
with foreign keys linking lower-level tables to their parents. As an
example, let's presume
Having read the authentication documentation, it's still not clear to
me how the permission system works. They merely say "has_perm(perm)``
-- Returns ``True`` if the user has the specified permission" - without
actually describing what 'perm' looks like.
Could someone post a illustrative code sn
Is anyone working on support for MS SQL Server? I've seen people
discuss it in the past, but have heard nothing specific regarding
'official' support. There's the following entry in the wiki, but
nothing more seems to be happening.
http://code.djangoproject.com/ticket/225
I'd like to use Django
Why not just NOT_PROVIDED = ''?
# Random entropy string used by "default" param.
NOT_PROVIDED = 'oijpwojefiojpanv'
Can anyone explain why this is necessary?
Ok- should be a trivial patch.
It seems as though 'self.default' is a string set to 'oijpwojefiojpanv'
when not set with a parameter in the models definition.
Whuh?
Otherwise, it's as easy as...
if f.default <> 'oijpwojefiojpanv':
field_output.append("DEFAULT '%s'" % (f.default,))
Only t
Suppose I have the following tables:
'Person'
idname
--
1 larry
2 moe
3 curley
'Activity'
iddescription
---
1 fighting
2 yelling
3 cracking wise
'Actions'
idpersonact
-------
1 1 2
2 3 2
3 2
FWIW-
I'm loading existing data into a Django-created schema. I suppose there
are other workarounds, but that would seem to be the best solution.
I'm having trouble finding where the sql is actually being composed.
Pointers?
This does not act as I expect:
foo = meta.BoooleanField(default='FALSE')
I would expect the produced SQL(for Postgres) to include a DEFAULT
'FALSE' clause.
Does the 'default' keyword only relate to html forms?
There doesn't seem to be anyway to create postgresql tables that use
inheritance from the Django model syntax. Is that true or am I missing
something?
21 matches
Mail list logo
