; "this won't work with mysql" :)
>>
>
> +1
Great! Then I'll relaunch my proposal for 'Choose Storage Engine per
Model' :)
-1 , unless it can be fixed in code and not manual.. Because saying
it 'Does not
choosing the backend.
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 independent. And Django is working fine wi
27;t validate any keys modified while the checks were
> disabled.
That's not good indeed. Not to be used to simulate deferred constraints.
> Or, is there another approach that I am not aware of?
No, not currently. Things are on their way, but that's all I can say
for now :)
C
Geert Vanderkelen wrote:
> Hi!
>
> I'm currently looking into a possibility to define per Model which MySQL
> Storage Engine it should use for creating the table. This would need a new
> option called 'db_table_option' for the Model.
..
Ok. Sorry for the noise,
Hi James,
James Bennett wrote:
> On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
..
> 1) The features common to all the RDBMS products it can be used with.
> 2) A way to manually tweak its SQL output to take advantage of
> features which only apply to one database.
Hi Adrian,
Adrian Holovaty wrote:
> On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>> I'm currently looking into a possibility to define per Model which MySQL
>> Storage Engine it should use for creating the table. This would need a new
>> option called
Hi James,
James Bennett wrote:
> On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
>> Not only for MySQL would this be handy, for other backends as well. I think
>> for PostgreSQL the inheritance feature would need this too.
>
> How so? Postgres doesn't ha
Hi Malcolm,
Malcolm Tredinnick wrote:
> On Mon, 2006-07-17 at 12:15 +0200, Geert Vanderkelen wrote:
>> A follow-up on my previous post, with a patch attached to make the
>> db_table_options work, which was easy to put in.
>>
>> Any comments on this patch, or something
and need.
>
> For example, following should be possible:
>
> CREATE TABLE t1 ( id int ) %db_table_options%;
--
Geert Vanderkelen
http://some-abstract-type.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
there are more things to change to make this work correctly..
I'm still trying to figure that out :)
What you guys and girls think?
Cheers,
Geert
--
Geert Vanderkelen
http://some-abstract-type.com
--~--~-~--~~~---~--~~
You received this message because you are sub
odel.
This mysqlext would contain stuff which really shouldn't go in the MySQL
backend of Django itself as it ain't fully compatible with others (I think
that's the idea of these I guess..).
Cheers,
Geert
--
Geert Vanderkelen
http://some-abstract-type.com
--~--~-~--~---
InnoDB
Again, depends on which version you are using. Small overview here:
http://dev.mysql.com/doc/refman/5.1/en/news-5-1-8.html
We might need to put that overview somewhere in manual though.. Gonna
check that out.
Cheers,
Geert
--
Geert Vanderkelen
http://www.some-abstract-type-shit.com
encodings..
Since this is probably going to be needed for all DBMS out there,
what about a DATABASE_ENCODING setting which will set the character
set for the connection?
Cheers,
Geert
--
Geert Vanderkelen
http://Kemuri.Org
--~--~-~--~~~---~--~~
You rec
, this could be a solution for other DBMS not having this
DATE_TRUNC() function.
Cheers,
Geert
--
Geert Vanderkelen
http://Kemuri.Org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
14 matches
Mail list logo