> OK, sourceforge's SVN is back up and from a brief look I don't think the tip
> of the trunk for MySQLdb is intended to be in general use. The comment
> associated with rev 530, current for connections.py and the one which
> introduced this change is: "Tons of changes from major refactoring/clea
On Apr 3, 2:39 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 3, 2008 at 2:18 PM, Tim Keating <[EMAIL PROTECTED]> wrote:
>
> > I should clarify - this is with MySQLdb 1.3.0 built from source, MySQL
> > 5.0.41 and Python 2.5.
>
> Whe
I should clarify - this is with MySQLdb 1.3.0 built from source, MySQL
5.0.41 and Python 2.5.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-deve
I have recently set up Django with MySQL on Mac OS X 10.5. I am
running into the following error:
File "/Users/tkeating/Documents/Projects/django/django/db/backends/
mysql/base.py", line 196, in get_server_version
m = server_version_re.match(self.connection.get_server_info())
AttributeError
Has anyone broached the subject of switching to a distributed source
control system, such as Mercurial? In such an environment, central
branches aren't needed; everyone with a copy of the source repository
can branch it on their local system. Mercurial also has a very nice
patch generation system.
I was wondering whether I could just grab django/contrib/search, and
now I know. Thanks! I'll give that a shot. Given that workaround, I
wouldn't worry about a downmerge right now, I know how time-consuming
they are.
TK
--~--~-~--~~~---~--~~
You received this me
Looks like this hasn't been touched much since SoC work got checked in.
Is there a timeline for getting it merged up into trunk?
If not, could we get a downmerge, so we can be using that branch and
still get all the juicy mainline django goodness to work with?
--~--~-~--~~-
Tom Tobin wrote:
> On 8/4/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> >
> > In Rails, template tags can have an extra hyphen at the end to denote
> > the fact that they should consume the newline right after the tag. So:
> >
> > {% some_tag %}
> >
> > Would look like this:
> >
> > {% some_tag
This has been brought up a couple of times. See
http://code.djangoproject.com/ticket/696, which was marked wontfix,
reopened, and marked wontfix again. It's clearly not a concern the core
devs care about.
The solution seems to be, write your own middleware.
TK
--~--~-~--~~-
Not at all -- it sounds like the answer is one of the ones I expected,
which was "Write a custom manipulator"
Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group
The ability of model A to return appropriate records in model B, where
B has a foreign key pointing to A (ergo a one to many relationship
where A is the one and B is the many). As described here:
http://www.djangoproject.com/documentation/db_api/#backward
--~--~-~--~~~---
Is there an existing way to create, say, a ChangeManipulator that
includes a backwards foreign key relationship?
TK
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
Would it be worthwhile for the people with a thorough understanding of
what's going on under the hood to create a tickets in Trac for the work
remaining to finalize m-r? Then you could ostensibly set a target date
for the completion of the milestone. That would give everyone something
to strive fo
The way I typically do this is:
1. Rename the schema.
2. Update my model files.
3. Re-run django-admin install install myapp.
4. Write SQL statements to migrate the data from the renamed schema to
the newly-regenerated schema.
This sounds riskier than it is, but my experience has been that as lo
Then don't use comments. Use docstrings.
hugo wrote:
> One nice thing about chained methods is, you can pass around the query
> object and modify it after the fact. Think "curried queries" - you
> build a partial query and pass it to a function, which itself can add
> more query specifications or ordering or stuff like that, without
> ne
I discovered tonight that when you create a manipulator from a model
that contains a ForiegnKey field, it generates a SelectField and
pre-populates the form field object's choices attribute with all the
possible values. So far so good . . . except that the primary key in
the related table is an Au
One quick question -- are you guys making the corresponding changes to
the docs? (The tutorials, especially.) If not, I may be able to do some
of that.
Fair enough. Somebody had to resist being a +1 sheep :-)
Well, how about this.
>From a user (and ease-of-entry) standpoint the simplest possible
syntax would be
from django import *
I don't know about most of you, but I'm already importing pretty much
all of Django anyway, so I'm not sure this is as expensive as it
sounds. With this approach, yo
I have been working on a file download link, where the file is
generated dynamically in the view code and returned via the mechanisms
outlined in the help for generated PDFs or CSVs. This works fine, but
the performance is staggeringly bad. When I prototyped the file builder
in a vanilla Python sc
Jacob Kaplan-Moss wrote:
> I'm -0.9 on the ".q" syntax, and -1 on having two competing lookup
> syntaxes.
I'm approximately -235 on multiple sytaxes. This is one of the reasons
I'm no longer using Zope.
TK
I second Hugo's take on the syntax. In general, anything that moves
away from a syntax for field lookup that differs from both the template
language AND Python gets a big thumbs up from me. But I also prefer the
syntax suggested in #980.
"Hate" is too strong a word. However, I do feel that this is not a
positive addition.
Django offers a nice three-tiered architecture in terms of information
presentation:
- Views, to select content.
- Templates, to organize content into manageable structures.
- CSS, to tell the browser how to
-1 from me. As a *user*, I would much rather just generate random
content inside of my view code. I'd like to point out the cited example
(random photo on Flickr) can't be done with this technique, since this
is baked into the template.
Robert Wittams wrote:
> Are you using the app template loader? templates go in /templates .
> Seems eminently sensible to me.
> The project wide stuff is useful for overriding app provided templates.
No, I'm not. Clearly I need to do some reading :-)
+1 for me; if you start thinking about doing the same with views, have
a preemptive +1 for that, as well :-)
Then maybe we can start talking about how wrong it is where templates
live right now . . .
TK
Regarding the original issue (putting the project directory into the
PYTHONPATH), is the implication that django-admin would automagically
append the directory where it locates the settings.py file to sys.path?
Or is this not intended to address that concern at all?
BTW Simon, beware; "knock up"
I just spent a couple of evenings tracing a crasher problem that turned
out to be caused by my data. I had some rows with date stamps with a
value of 0 (legacy data). In typecast_timestamp(), this generates a
ValueError because you can't create a datetime object with a year of
less than 1.
This w
It's an interesting idea . . . I know why perforce works this way, but
I'm curious what problem this addresses. Most of the stuff that lives
in the P4CONFIG file is located in /settings.py, as far as I
can tell. And I'm not clear how this would solve the problem of Python
knowing where to look for
I have recently discovered the joy of .pth files. I respectfully submit
that having django-admin create one of these for you as part of running
startproject would be a cleaner (and more cross-platform) solution than
what you propose here.
Implementation details aside, +1 for the idea!
Well, if you try to use it with any other db backend atm, you will get
a "NotImplemented" error. That should be pretty clear :-)
The other thing about this patch is it only addresses half the problem
-- there's no support in the model for setting up fulltext indexing.
But hopefully, that will be
ot;match" definitely hews to that
syntax. So I thought it was worth raising for discussion.
Tim Keating
Actually, you could always download the express edition for free for
development purposes (you just had to sign up for Oracle TechNet). The
change to allow limited deployment is the only change, AFAICT.
Nevertheless, good news.
> Yes indeed. Like for example that it is in general NOT a single-step
> process! Sometimes you *have* *to* make a partial change, futz with
> things, then complete the change. The sane way to do that, IMO, is to
> manipulate the database using a language designed for database
> manipulation (e
I can't say from practical experience, but I'm doing something similar
and I can tell you what I'm *planning* to do: I am going to pass the
search string to a lexer function that will rip it apart into various
constraints. The constraints are returned as arguments to pass to the
get_list function
36 matches
Mail list logo
