I noticed (after inferring it probably exists) the
RequiredIfOtherFieldsGiven validator, though it is currently
undocumented. The default error message is, "Please enter both fields
or leave them both empty." The actual test is:
def __call__(self, field_data, all_data):
for field in
On 11/1/06, Yasushi Masuda <[EMAIL PROTECTED]> wrote:
>
> As in the ticket #2866, I think it would be nice if DatabaseWrapper has
> extra keyword options, which are passed to individual DB-API connection
> object constructor.
+1
I had been thinking about putting a patch together for the MySQL
ba
On 12/22/06, yichao.zhang <[EMAIL PROTECTED]> wrote:
my env:
python 2.4.3, django-0.95-py2.4, WinXP sp2
I created a new project, enabled the admin feature.
After logging into admin as superuser, I press the button "Add user",
then the following error occurs. It's reproduciable against mysql an
On Feb 27, 6:38 pm, "Ramiro Morales" <[EMAIL PROTECTED]> wrote:
> On 2/27/07, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>
>
>
> > Because the other Databases have 'limitations' or 'features' or
> > 'defects' that MySQL might not have or whatever. Django is, as I have
> > been told, database ind
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.
--
Patriotism
On 3/1/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Andy Dustman:
> > Here's another possible solution/workaround: MySQL supports an IGNORE
> > keyword on INSERT statements, which causes errors to be treated as
> > warnings.
> >
> > htt
Also, MySQLdb-1.2.1 is the first version which has support for
MySQL-4.1, and MySQlL-4.1 is the first version with good character set
support (in prior versions the client could not change the character
set) and sub-selects. MySQLdb-1.2.1_p2 has an important bugfix, but it
only matters if you are
On 3/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Also, the link in http://code.djangoproject.com/ticket/3279#comment:14
> seems to indicate there are some real problems with 1.2.0.
If there weren't problems, there wouldn't be a 1.2.1. :)
> Or is that
> not consistent with your underst
On 3/28/06, pbx <[EMAIL PROTECTED]> wrote:
>
> At this point I'm just pretending magic-removal *is* the trunk. I've
> ported all my play stuff to it, am using the admin to manage content
> for a couple existing non-Django sites, and am developing a production
> site in it at work now as well. Most
On 3/30/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've created a patch that allows inspectdb on mysql databases to
> recognize the foreign keys; I'd like someone using mysql 5 to test this
> patch if possible (I have only mysql 4 here, and I don't plan to use
> version 5 ... but I
On 3/28/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>
> Andy Dustman wrote:
> > It might be worth considering puting in some backwards-compatibility
> > with 0.91, though, keeping a meta module but giving a deprecation
> > warning if it's used, warning if yo
On 3/31/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
> Line 17 reads:
> @@ -12,8 +18,58 @@ def get_table_description(cursor, table_
>
> Can anyone tell me what I'm actually doing wrong?
I don't know, but those are two lines mashed together somehow. How are
you generating that diff?
--
The Pyth
On 3/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> Could anyone who want's mixins post some specific use cases
> (preferably simple code samples) Basically, are people wanting
> multiple inheritace for models, or do you just want a mixin to provide
> some additional methods? I'm reasearc
On 3/31/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 3/31/06, Andy Dustman <[EMAIL PROTECTED]> wrote:
> > I have some notes on the ModelInheritance page about possibly using
> > views to simplify reading, and while none of the databases I could
> >
On 3/31/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Mar 31, 2006, at 1:30 PM, Alan Bailey wrote:
> > IsModified()
>
> This could be useful, but it's probably not worth doing since Django
> would have to keep two copies of all your data in memory to figure
> this out. Doubling the mem
On Tue, Sep 25, 2012 at 7:57 PM, Russell Keith-Magee
wrote:
> On Tue, Sep 25, 2012 at 11:24 PM, maxi wrote:
>> No, I just answer because it caught my attention. Why not just trust in a
>> True/False property ?
>
> As I recall, the reason we can't just use a property is MySQL. There's
> no reliabl
You can do something like:
for row in cursor:
dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
(izip may be better than zip. Your call.)
Or for the whole result set:
result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
for row in cursor ]
On Thu, Jun 16,
And if is a real problem in the MySQL support, I'm willing to look
into it. I use it in production. You might have to poke me directly
but I am trying to pay attention lately.
On Thu, Jun 23, 2011 at 5:53 PM, Jacob Kaplan-Moss wrote:
> Hi Jim --
>
> Historically, most Django core developers have
On Mon, Jun 27, 2011 at 6:08 PM, Jacob Kaplan-Moss wrote:
> On Mon, Jun 27, 2011 at 4:24 PM, Jim D. wrote:
>> I spent some time last week and over the weekend nailing down a
>> solution for https://code.djangoproject.com/ticket/3615 . This is the
>> ticket about allowing forward references when l
On Thu, Jun 30, 2011 at 4:51 AM, Daniel Swarbrick
wrote:
> The main difference between MySQL's "timestamp" field type and
> PostgreSQL's "timestamp with time zone" field type (and indeed also
> MySQL's "datetime" field type) is the date range that they support.
> MySQL's "timestamp" field type is
On Thu, Jun 30, 2011 at 12:24 PM, Daniel Swarbrick
wrote:
> On Jun 30, 5:12 pm, Andy Dustman wrote:
>
>> Uh, no. -00-00 is specifically an illegal value in MySQL. Invalid
>> dates are converted to -00-00 unless you are in strict mode, in
>> which case they rai
If you aren't using InnoDB, then it probably doesn't matter if you turn
foreign key checks on or off: it becomes a no-op. There are some other
storage engines that support transactions, and some of them might "do the
right thing" with respect to deferred foreign key checks, but I think it
does no h
22 matches
Mail list logo
