Question about manipulators with foreign keys
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, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Question about manipulators with foreign keys
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Question about manipulators with foreign keys
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, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: the template system's whitespace handling
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 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: the template system's whitespace handling
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 -%}
>
> I can't help but feel that this syntax is ugly and, furthermore, easy
> to miss while scanning through a template. I wouldn't mind having to
> set something once in my root-level template (e.g., {% chomp %}{%
> endchomp %}) if it was picked up by child templates inheriting from
> it.
I agree. It seems to me people either care about this or they don't.
Ergo the Django way to do this would be to make the whitespace handler
pluggable and set it globally in settings.py.
TK
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Search API branch status?
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? --~--~-~--~~~---~--~~ 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: Search API branch status?
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 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: Schema Evolution branch?
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. And I'm led to believe there's a plugin for using it with Trac. (Edit: now that I do a quick search, I see that it has been mentioned a couple of times, but not discussed in any kind of serious way.) TK --~--~-~--~~~---~--~~ 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: Jumping views
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 of your model.
Re: database_check / Ticket #12
> 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 (eg., SQL), then get Django's model back in sync. The > alternative (that would work in general) would be to add all the > functionality of SQL to what is presently a simpler langauge designed > only to describe a static schema; of course, doing so will make it less > simple, compromising one of its current virtues. Arguably, making the canonical descriptor of your data structures the database (which AFAIK is how Rails does it) has advantages over making it the code and building the db from that. However, I don't foresee django changing to that model, and we play the hand we're dealt, right? IMHO the best way for this process to work seamlessly is to forcibly make the db tables match the structure dictated by the current version of the model. Before doing so, however, do some analysis to detect changes that would cause data loss, build scratch tables & move the data over, and present the user with a set of template sql statements -- "Hey, user, updating your table structures lost this data, if you want it back, here it is . . . or if you don't want it anymore, run this statement to drop the table."
Re: FYI: Oracle has free edition now
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.
Patch submitted for fulltext search under MySql
This is attached to ticket #593 (http://code.djangoproject.com/ticket/593). The patch adds a "match" lookup_type that gets converted into a where clause entry for a full-text search. I'm not convinced this is a good long-term solution, since tt's MySql-only at present, and "match" definitely hews to that syntax. So I thought it was worth raising for discussion. Tim Keating
Re: Patch submitted for fulltext search under MySql
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 forthcomng.
Re: A fix for all that futzing around with paths
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!
Re: A fix for all that futzing around with paths
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 your project files in the first place.
Date value of 0 issue
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 was a real pain to find, because it wasn't immediately obvious that it was bad data. (Part of that is due to the fact that the MySQL driver does some error handling nonsense that obfuscates the real source of the error . . . so it looked like a driver problem.) I can fix the problem by fixing my data, but this strikes me as the kind of thing a casual developer could come across and be REALLY daunted. It seems like we could handle this situation better, but I'm hanged if I know what the Right Thing to Do is. Give a more meaningful error message? (Is it necessarily an error to have a date value of 0?) Convert to NULL? Something else? I'm willing to write up a patch for this. Anyone care to offer a suggestion as to how to fix it? TK
Re: A fix for all that futzing around with paths
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" means something VERY different on this side of the Atlantic . . . TK
Re: Proposal: models.py by default instead of "models" directory
+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
Re: Proposal: models.py by default instead of "models" directory
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 :-)
Re: Random Tag
-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.
Re: Random Tag
"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 draw those structures. We already have the ability to generate randomized *content* by writing some fairly simple Python, and that's what it sounds like the intent of this tag is. However, based on my (admittedly, highly subjective) perception of the three-tiered architecture, templates are not the place for generating content. It isn't that I object to adding logic to the template layer -- some logic is inevitable because some form of code is the easiest way to perform certain layout tasks (e.g. assembling a table). If this tag was meant as a way to scramble your LAYOUT, then I would be right behind it, but I don't see anyone suggesting that as a way for this to be used. (Nor do I imagine there's a real demand for that functionality :-) My apologies, I hate to be negative about someone else's hard work. TK
Re: Removing the magic
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.
Re: Removing the magic
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
ORM performance question
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 script and ran it from the shell, it wrote the file out to disk in about 3-4 seconds. Simulating the query using the Django ORM caused it to take almost a full minute to do the same task. I modified the code to run under hotshot, which had some surprising results. Basically, what I'm doing is: for foo in foos.get_iterator(): # Pack some of the data into a binary buffer I expected to see 1 call to function_get_iterator, or, at worst, 1 call for every GET_ITERATOR_CHUNK_SIZE rows. Instead, I'm seeing *3* calls to function_get_iterator for every row, which I find perplexing. I intend to dig into this further but I thought perhaps someone who's been elbow-deep in the ORM could offer some enlightenment, rather than sending me in there cold turkey.
Re: Proposal: Django namespace simplification
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, you don't have to CARE about how the subprojects are organized until you are a much more experienced user (or have labelled yourself a developer :-), which IMHO is as it should be.
Re: Proposal: Django namespace simplification
Fair enough. Somebody had to resist being a +1 sheep :-)
Re: Proposal: Django namespace simplification
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.
Concern with manipulator and foreign key
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 AutoField, so it shouldn't be possible to assign to it. Is this a bug? Is there a way to suppress this behavior? I tried assigning limit_results_to in the model definition but that doesn't seem to apply to the creation of the form field. This is a performance concern, since I'm seeing a noticeable pause (3 or 4 seconds) with only 50K rows in the DB . . . I can't imagine how painful this would be with 10x or 100x the data. TK
Re: DescriptorFields status/Manager API change
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 > needing to know about what the actual query is. This opens up a really > nice way to build generic code: you only need to put those query > specifications into your code that _your_ code needs, any filtering for > example can be done outside. > > And I think all/filter is quite nice, too - that way you can see > directly whether a query starts with the full set or wether you work on > a subset. Sure, this can be done with one single method with > parameters, but I rather like the distinguished method names - it's > more readable to me. +1 to this argument from me. I, too, like "all/filter" -- explicit is better than implicit. TK
Re: "Need automatic process support,(Re: How about converting python config files to text config files)
Then don't use comments. Use docstrings.
Re: Database migration practices?
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 long as your DB does the right thing with auto fields, it's fine. TK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Status of magic-removal
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 for . . . and if the date has to slip, it's not like the stock will go down :-) The other upside to this is, there's probably a bunch of scut work that needs to get done. If that was written up, it would be easier for eager but less well-versed developers (like me) to take some of it off the folks who are doing the heavy lifting. TK --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
MySQL backend: does get_server_version() rely on magic in the MySQLdb build?
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: 'Connection' object has no attribute 'get_server_info' As I look at this, I don't get how it's even SUPPOSED to work. self.connection is created by calling MySQLdb.connect, which returns a DB API conformant Connection object. This interface HAS no get_server_info() func; the only way to get access to that (MySQL- specific) function is to import _mysql and call connect() on THAT instead -- but that connection object type is *not* DB API-conformant. It appears that the correct way to get the server version would be to access MySQLdb.connect()._server_version (which unfortunately only exports the first 2 digits). Is this relying on some kind of magical undocumented behavior in MySQLdb that I failed to bake in when I built it? TK --~--~-~--~~~---~--~~ 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: MySQL backend: does get_server_version() rely on magic in the MySQLdb build?
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-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: MySQL backend: does get_server_version() rely on magic in the MySQLdb build?
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. > > Where did you get MySQLdb 1.3.0? Latest I see at sourceforge > (https://sourceforge.net/project/showfiles.php?group_id=22307) is 1.2.2? > > In 1.2.2, a MySQLdb Connection is based off of (inherits from) a > _mysql.connection, therefore you have access to the _mysql specific routines > from the MySQLdb Connection. This is apparently not true for whatever you > are running? > > Karen I got 1.3.0 by syncing to the svn trunk. The definition of a connection in 1.3.0 looks like this: class Connection(object): """MySQL Database Connection Object""" So if there previously was an inheritance relationship, that appears to be going away. I'm not able to confirm this for sure because Sourceforge's SVN repository appears to be unavailable right this second. Looks like they may have replaced inheritance with composition: self._db = _mysql.connection(*args, **kwargs2) If so, the fix is to interject a "_db" into the calls to self.connection.get_server_info() and self.connection.ping(). If my take on this is correct, this is going to break for a lot more people when 1.3.0 gets officially released. TK --~--~-~--~~~---~--~~ 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: MySQL backend: does get_server_version() rely on magic in the MySQLdb build?
> 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/cleanup. > This is all really broken right now. In particular, all results are returned > as strings." > > Sounds like there are major changes going on and picking up a non-released > revision is a bad idea. Agreed, that was the root of my mistake. However, it strikes me that a change of this nature is not something accidental, so it is probably really coming... eventually. Updating the mysql backend to deal with it robustly is probably a smart move. I have emailed Andy Dustman (the principal developer on MySQLdb) and asked about this change; once I hear back from him we'll know whether a patch needs to be made. TK --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
