On Jan 30, 8:49 pm, "Dan Kubb (dkubb)" <[email protected]> wrote:
> Mister,
>
> > I may be mistaken, but I find I'll have to set some low level mysql
> > table-level settings. Unfortunately, the current property list for a
> > table doesn't appear to support the following:
>
> > ENGINE = InnoDB (or does dm fake transaction support?) Just don't want
> > to be tripping on toes here.
>
> > CHARACTER SET seems its utf8 by default, but:
> > COLLATE I'll need to set to 'utf8_bin' (or it messes up some german
> > strings) *prior* to adding string columns.
>
> Greg Campbell committed some fixes in dm-more that will make it into
> the next gem release:
>
> http://github.com/datamapper/dm-more/commit/ba9e29e13ffa506978530b729...
>
> NOTE: To use edge dm-more, you'll also need the edge versions of dm-
> core, DO, and extlib.
>
> The tables will all be created with InnoDB. The character set and
> collation are determined by your connection settings. With do_mysql I
> believe you can specify the :encoding option when setting up your
> connection, but I do not think there is a way to specify the collation
> yet.
>
> You may want to look at MySQL's docs to see if there's a way to
> configure the default collation in the my.cnf. I'm sure there is,
> I've never found anything I wasn't able to configure that way.
>
> > AVG_ROW_LENGTH, and MAX_ROWS I'll have to set on large deployments or
> > I'll run into a file size limitation.
>
> DM and DO don't have ways to configure these options. For these you
> will need to consult the MySQL config docs.
>
> --
>
> Dan
> (dkubb)
Well, I'm not going to be able to always edit the my.cnf file on
systems my application is deployed on. Also, AVG_ROW_LENGTH and
MAX_ROWS are *very* table specific are not to be globally set. As
with COLLATION I'm perfectly happy to set these in a custom migration
for now (If I can figure out how). It is nice to hear the up coming
improvements to numeric properties, ensuring InnoDB, etc. - excellent
ideas :) .
One problem I'm looking at now attempting to get a custom migration
going is that I think I need to get the value of db_name, but of
course - its a private method. Would it break anything to render this
method public in future releases? The reason I think I need this is
that during an execute command, with mysql, I believe I need to
specify the absolute path to the table I'm modifying: repository
(:context).adapter { execute "ALTER TABLE '"db_name"'.'table' blah
blah" } ... any ideas?
This code snippet should indicate the direction I'm going with dm-
migrations:
repository(context).adapter {
migration 1, :create_prototype_table do
up do
create_table :prototype do
column :dbid, Integer,
:serial => true
end
if
repository().adapter.uri().scheme == "mysql"
execute ("ALTER TABLE
`" + repository().adapter.db_name +
"`.`prototype` ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_bin;")
end
modify_table :prototype do
add_column :title,
String, :size => 255
end
end
down do
drop_table :prototype
end
end ;
migrate_up!
}
As you can see, I need a come to jesus meeting with a skilled
migration master to get this right.
It would be nice, within a class def, to have some properties that
help a bit with custom migration efforts. What about a
property :after_create_table do if repository().adapter().uri.scheme
== "mysql" execute (sql) end end *or* :before_create_properties do if
repository().adapter().uri.scheme == "mysql" execute (sql) end end?
Basically, something that you can strategically wedge into the event
chain at each level (table, property) to make the settings changes as
needed. A few changes in this area would basically eliminate the need
to do custom dm-migrations at all I think. Is this currently
possible, but I don't know about it?
Thanks for the speedy reply to my questions btw. If the incumbent
custom-migrations guru will take some time with me, I'd be happy to
document/write up a how-to on some of this stuff as I'm positive it
will all get asked again.
Cheers,
G. Gibson
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---
