On Mar 1, 7:10 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I've tried several times to attach files of a sample project and sql
> dump to Ticket #3613 several times, and trac keeps throwing an
> error does one need special permissions to do this? ( I'm using
> firefox. )
What's the
On 2/27/07, Bas van Oostveen <[EMAIL PROTECTED]> wrote:
> As with js u can add some javascript to fields of your choosing, an added
> option
> css would let u add a file with the 2 extra .imgfoo {} and .imgbacon {} css
> classes.
I think one of the goals of the admin reworking is that it'll be
HOW TO MAKE EASY MONEY FAST AND LEGALLY
This seems to really have potential. This is the way the original post
appeared when I first found it. Read it all then decide for yourself.
It works for me! I found this on a bulletin board and decided to try
it. A little while back, I was browsing
> If the id already exists, you will overwrite the record; if it
> doesn't, it will be created. This is the same behaviour as your
> approach.
This is exactly what I DON'T want to do and Django ALWAYS does.
> For the future - this question should be asked on the users list. The
> developers
Hi it seemed to be a good change to give the admin its own space. Btw
what about the field specific items like
edit_inline, max_num_in_admin, ...
an so on. Have you made any decision where this should be set in
future or if this will be left in the model?
Tom
I've tried several times to attach files of a sample project and sql
dump to Ticket #3613 several times, and trac keeps throwing an
error does one need special permissions to do this? ( I'm using
firefox. )
--~--~-~--~~~---~--~~
You received this message
On 3/1/07, Rubic <[EMAIL PROTECTED]> wrote:
>
> On Mar 1, 3:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > AFAIK it will be migrated eventually to being 'max_length' everywhere,
> > but probably not for this release because that's a
> > backwards-incompatible change.
>
> One possibility
On Mar 1, 3:12 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> AFAIK it will be migrated eventually to being 'max_length' everywhere,
> but probably not for this release because that's a
> backwards-incompatible change.
One possibility would be to allow max_length to be
used as a maxlength
Andy Dustman:
> Here's another possible solution/workaround: MySQL supports an IGNORE
> keyword on INSERT statements, which causes errors to be treated as
> warnings.
>
> http://dev.mysql.com/doc/refman/5.0/en/insert.html
>
> Not sure how hard it would be to incorporate this for this particular
On 3/1/07, Kai Kuehne <[EMAIL PROTECTED]> wrote:
> Could you decide on whether to name the attribute maxlength or max_length?
> Well... it's not *that* important but it this is ugly, imho.
AFAIK it will be migrated eventually to being 'max_length' everywhere,
but probably not for this release
Could you decide on whether to name the attribute maxlength or max_length?
Well... it's not *that* important but it this is ugly, imho.
http://code.djangoproject.com/ticket/3622
Greetings
Kai
PS: I like the mood here, thanks to everybody. :)
On 3/1/07, mralokkp <[EMAIL PROTECTED]> wrote:
> I guess This Group could help me.
No, actually you were right to post the question to django-users.
This list is for discussion of developing Django itself, not questions
about using it.
Thanks!
Jacob
Here's another possible solution/workaround: MySQL supports an IGNORE
keyword on INSERT statements, which causes errors to be treated as
warnings.
http://dev.mysql.com/doc/refman/5.0/en/insert.html
Not sure how hard it would be to incorporate this for this particular
case, though.
--
Hello All
I don't know that this Question is asked here or not but I am stuck in
a problem.
The Problem is here
http://groups.google.com/group/django-users/browse_thread/thread/921e8e8f5a68ec7a
I guess This Group could help me.
Thanks in Advance.
A
> Could this be related to #2874 ?
2874 looks related in that it is another bug resulting from a similar
type of circular table relationship.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
On 3/1/07, David Larlet <[EMAIL PROTECTED]> wrote:
> What about bug #2282? What's the actual status? A patch is proposed,
> it doesn't suit any case but it's a good start for a part of the
> world.
It still needs a discussion and decision about how far we want to go
to support (essentially)
> ...In which case, you'd get still get an error if there was a
> collision on ID, and you'd still need to generate a new ID and try
> again. I guess you're just trying to avoid the "check if a record
> with that pk exists" bit on inserts? And you (the app dev) would be
> responsible for
On 3/1/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
...
> That's ok. All we are trying to say is that INSERT code should be a
> separate function which can be used independent to UPDATE code.
...In which case, you'd get still get an error if there was a
collision on ID, and you'd still need to
> The current code is:
> if pk_set:
> check if a record with that pk exists.
> if it does, do an update.
> if it does not, do an insert.
> else:
> do an insert.
>
> If you abandon the record check when pk_set, then you lose the ability
> to manually specify an ID for use in insert.
> If you abandon the record check when pk_set, then you lose the ability
> to manually specify an ID for use in insert.
Thats why the comment above says "simplified", perhaps it was
oversimplified...:
---
def save(self): # not
> Perhaps save() could be change to actually do this:
> (As I started writing my own DB-abstraction-layer once, I know this can
> become very handy)
> ---
> def save(self): # simplified
> if self.id:
> self._update()
>
On 3/1/07, David Danier <[EMAIL PROTECTED]> wrote:
...
> Perhaps save() could be change to actually do this:
> (As I started writing my own DB-abstraction-layer once, I know this can
> become very handy)
> ---
> def save(self): #
On 16 Gen, 16:19, "Victor Ng" <[EMAIL PROTECTED]> wrote:
> I'll try to have a repo setup for people to play with this week -
> getting schema-evo stabilized isn't something that the core-devs
> should have to be involved with anyway.
This feature is very interesting and I may help with some
> I should be able to do it with just one
> hit at the database. Second (and subsequent) hit(s) should occur only
> in the case of an insert exception (AssertionFailed). But the way
> Django doesn't differentiate b/w INSERTs and UPDATEs, I have to
> manually check for collisions and hit the
24 matches
Mail list logo
