Hi , We will be enabling the following storage engines:
myism archive-storage-engine blackhole-storage-engine csv-storage-engine example-storage-engine federated-storage-engine innodb and innodb storage engine Shall update the draft accordingly. Regards, Ritu Jan S Berg wrote: >Hi Jyri, > >thanks for comments, answers in-line > >Jyri Virkki wrote: > > >>http://wikis.sun.com/display/WebStack/MySQL50ArcCase >> >> >> >>>Including MySQL 5.0 with Solaris - DRAFT >>> >>>17 October 2007 >>> >>> >> >> >> >>> 2.6 Configuration and Enviroment settings. >>> >>> >>As which user will it be defined to run as? >> >>(Since it reads ~/.my.cnf, this seems like a good section to cover >>that info.) >> >> > >ok, standard distribution suggests to install as user mysql and group >mysql, and I think we should go for the same. Will update the ARC case >with this. > > > >> >> >> >>>3. Core Modules >>> >>> The MySQL server has several storage engines built in >>> (specified when you create tables), the primary ones are: >>> InnoDB - ACID storage engine >>> MyIsam - non-ACID storage engine >>> Other engines exists, see mysql.org[1] for details, where >>> we will include the engines as the standard distribution. >>> >>> >>The last part of the sentence there is confusingly worded IMO. >>I think you mean that all of the built-in storage engines will >>be included in the build delivered by this case? >> >> > >I think I will list the storage engines we deliver, as there are other >engines available, but not part of the standard distribution. > > > >>Also, the section is titled "Core Modules" but talks only about >>storage engines. Leads to the question, are there any other kind of >>core modules beside the storage engines? >> >> > >I think to rename the heading to be Storage Engines, and they are >included/not included at compile time. They are not dynamically added >later. > > > >> >> >>>6. Packaging and Delivery >>> >>> We propose to package MySQL under the following packages: >>> >>> SUNWmysql50 - Server package (including server deamon, C API, >>> man pages, I18N) >>> >>> >>For sfw you need to deliver usr and root packages so you'll need at >>least SUNWmysql50r and SUNWmysql50u. >> >>(Look around in the sources under src/pkgdefs/* for examples.) >> >> > >ok, will update with these. > > > >>> SUNWmysql50test - MySQL test packages >>> >>> >>Aside from the file path mentioned in s2.5 and the package name above, >>this doc doesn't say anything about this test suite. What does it do, >>why does it need to be shipped with the server? Add a section that >>covers this topic. >> >> > >This is test programs that comes with the standard distribution, but >they are not necessary to run the MySQL server and other binaries. >They are necessary to ensure that our way of building MySQL does not >break any functionality. >Is there some common way to put these test programs? I think it is >nice to have this package available, but might not be installed by default. > > > >> >> >>> 7.3. Exported Interfaces >>> >>> >>The smf info is not listed, that's also an exported interface, please >>add. >> >> > >Ok, will add interface as well as manifest in the files listing. >Another point is that mysql cannot run out of the box with smf, as you >have to run mysql_install_db first to create the system tables as well >as set the database root user password (not to be confused with the root >user in solaris) > > > >> >> >>> NAME STABILITY NOTES >>> >>> MySQL Server Committed Server deamon program >>> >>> >>As I mentioned last time, this is not very clear. What is the case >>exporting here? >> >> > >It is the MySQL server binary. The interface should maybe be the "server >program command line options" ? > > > >>A useful way to think about exported interfaces is to picture you are >>writing script or code which interacts with the system somehow, >>document those points of interaction. >> >>Not clear how my hypothetical script interacts with "Server deamon >>program"? >> >> >> >>> MySQL Server config file Committed Config file >>> >>> >>Config file syntax or location? >> >> > >Config file syntax. > > > >>> Error messages Committed I18N Translated Error codes. >>> >>> >>Can you clarify on these? Codes (i.e. numeric error codes) or >>human-readable messages? >> >>If the latter, messages are not usually Committed. That would mean >>the words will never change, so it is not possible to reword the >>message to be clearer nor to fix a spelling mistake or anything, >>because it is ok for customers to write scripts which grep for the >>exact string of the message. >> >>Message text is typically "Not-an-interface", see >>http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ >> >>Given that, are these error messages really Committed? I'm not saying >>they can't be, if that's how the MySQL development community treats >>them, only want to reconfirm since it is unusual. >> >> > >ok, error codes should be Commited interface while the messages can >change as you say, so they should be UnCommited. So scripts should rely >on the errorcodes and not messages. Should both be listed here as >interfaces? > > > >> >> >> >>>================================================================ >>>Addendum 1: MySQL Integration Directory and File Structure. >>> >>> >>Please also list the soft links in the file listing. >> >> > >ok, will update this as well as the smf metafile and start script > >Thanks for comments! > >Jan S > > > >>thanks... >> >> >> > >_______________________________________________ >webstack-discuss mailing list >webstack-discuss at opensolaris.org >http://mail.opensolaris.org/mailman/listinfo/webstack-discuss > >
