> If so, is this something that would work reasonably seamlessly on top of
> J Pellerin's multi-database Summer of Code work (different engines =>
> different connections => essentially different database for that model,
> so it falls out of his configuration changes)?
Sort of. But mostly not. Th
DavidA wrote:
> improve it a bit:
>
> 1) In addition to providing initial data in a file
> /sql/.sql, I think it would be good to support a
> form of /sql//.sql so if you want to put
> DB-specific stuff in there you can. That way if I moved my app to
> PostgreSQL, for example, it wouldn't try to
Geert,
Just for the record, I use the "SQL initial data file" feature that
Adrian mentioned to enable full-text indexing on a couple of my tables.
The relevant part of my script is:
ALTER TABLE data_rawtrade ENGINE=MyISAM;
CREATE FULLTEXT INDEX ix_ft_data_rawtrade_all
ON data_ra
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, idea binned by all mighty FAQ. :
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> No.. This is about table options. All of them! Not only storage engine
> choice. All of the table options anyone can imagine.
And "all of the table options anyone can imagine" are supported by
that FAQ answer, as long as they can be appli
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> No.. This is about table options. All of them! Not only storage engine
> choice. All of the table options anyone can imagine.
I still feel like it's way too much of a special case to try to do
this; the proposed option of an "anything goe
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.
Well, my 'manually' t
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 'db_table_option' for the Model.
On 7/17/06, Geert Vanderkelen <[EMAIL PROTECTED]> wrote:
> This storage engine choice was only an example. There are lots of other
> options which can be set per table.
> As Honza replied, this is not MySQL specific and PostgreSQL as well as other
> DBMS accept options like these.
But pretty much
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 'db_table_option' for the Model.
>
> Not only for MySQL would this be han
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 have multiple storage engines like
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 I looked over? Otherwise I
On 7/17/06, James Bennett <[EMAIL PROTECTED]> 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 have multipl
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 have multiple storage engines like MySQL
does; a Postgres table is a Postgr
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 I looked over? Otherwise I make a
> feature request with it, unless I
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 I looked over? Otherwise I make a
feature request with it, unless I missed it while searching for an existing
one..
-Geert
Geert Vanderk
16 matches
Mail list logo
