> I'm really, honestly baffled by this statement. Django development
> happens in the open. Always has. Anyone anywhere at any time can look
> at what's going on, see what the dev team is talking about, etc. And
> it's not like the places where the discussion happen are a super top
> secret; a l
On 9 jun, 05:00, "James Bennett" <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 8, 2008 at 9:51 PM, Ashish <[EMAIL PROTECTED]> wrote:
> > my proposal is
>
> You do know that a list of what has to happen before 1.0, and a page
> listing the status of each item, has been available for quite some
> time
Hi from the Jeroen guy ;)
As you can see my version of mixing sqlalchemy and django is a bit
dormant. At the very least it needs some changes to work with
sqlalchemy .4. Besides my code is a bit sloppy, as much of the
translation django syntax -> sqlalchemy syntax was trial and error.
What my so
I've uploaded the code to my website.
http://jeroen.concept-q.com/projects/djangoalchemy/
(I'm sorry to admit that the website is plain unworkable in IE6, and
slow in other browsers. My use of transparency proves a tad ambitious)
--~--~-~--~~~---~--~~
You receive
to_one
relations via foreign key are supported as far as relations go. I
foresee formidable headaches to implement generic relations. And
transactions haven't even crossed my mind yet ;)
On 1 apr, 14:39, "Norjee" <[EMAIL PROTECTED]> wrote:
> There are more people tryi
There are more people trying to integrate sqlalchemy with django:
http://blog.case.edu/bmb12/2007/03/thinking_about_taking_over_the_djangosqlalchemy_branch
Perhaps a wiki page should be created on which all persons working/
thinking about sqlalchemy integration can discuss things a bit..
It's be
n found in pylucene-dev :
>
> changed django/utils/autoreload.py
> from:
> import thread
> to:
> import PyLucene.PythonThread as thread
>
> Norjee a écrit :
>
> > Pylucene has some threading issues (read incompatibilities with python
> > threads, it must be
Pylucene has some threading issues (read incompatibilities with python
threads, it must be run from either the main thread, or its own thread
version).
The solution is rather simple, use it in its own separte thread. See
for example turbolucene, http://dev.krys.ca/turbolucene/
--~--~-~-
At the moment BaseHandler is tied to RegexURLResolver. This makes it
impossible to change the urlresolver in a convenient way. (For the
mod_python handler it's easy, just extend the mod_python handler, but
for the development server you cannot change the handler) Thus django
core code must be alte
> On 14 mrt, 01:40, "Honza Kr=E1l" <[EMAIL PROTECTED]> wrote:
>
> for this use DateField( default=3Dmodels.LazyDate() ), it will do
> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> me
> On 14 mrt, 01:40, "Honza Kr=E1l" <[EMAIL PROTECTED]> wrote:
>
> for this use DateField( default=3Dmodels.LazyDate() ), it will do
> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> mea
> On 14 mrt, 01:40, "Honza Král" <[EMAIL PROTECTED]> wrote:
>
> for this use DateField( default=models.LazyDate() ), it will do
> exactly what you want: supply a default value of NOW() when no
> timestamp is given.
>
> It seems redundant to replicate this with the auto_* stuff, those are
> meant
Both have the behaviour that "the current date is always used". For
auto_now, it meas it is impossible to set a custom timestamp. For
auto_now_add it means you first have to create the object, save it,
set custom stamp, save again.
First it is odd that if it is intended for the timestamp to be wr
It might be wiser to wait for (a decision on) the root view solution.
Url reversing is more complex than the current setup allows. For
example predefined values in the routing setup are llowed, the reverse
url tag should be able to access these (think about setting https=1,
then https url would b
I would prefer the root view solution.
Url reversing is more complex than the current setup allows. For
example predefined values in the routing setup are allowed, the reverse
url tag should be able to access these (think about setting https=1,
then https url would be generated (-1:http url, 0:
The main thing i'm missing is a workable reversed url resolver. Or at
least an easy way to define/extend the current implementation. There
was already some discussion about it (see Proposal: Root view). As it
seems such a thing, while being said to be backwards compatible, change
the current way u
Regarding the, apparent, less than optimal participation, I think it
might help to dedicate a section on the Django homepage to development
in general or these branches in particular. It's a bit difficult to
find out what needs to be done, it is only posted on this google
discussion group, and aft
Just in case someone is needing something like this too, i created a
patch: http://code.djangoproject.com/ticket/2615
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
Apparently in the current trunk reversed urllookup is sort of working.
After toying with it a little bit I found an issue:
The main method, reverse, only returns the resulting matched url. Not
the rule (the regex and extra arguments) it matched. There is no
reliable way of knowing which (kw)args
19 matches
Mail list logo
