- docs - lists.mariadb.org

[Maria-docs] MariaDB table and field comments - character limits
by deoren 19 Mar '15

19 Mar '15

Hi, I've been learning SQL off/on for a while and have recently begun using MariaDB. While looking over the documentation, I found this page: https://mariadb.com/kb/en/mariadb/create-table/ and noticed that it mentions the the limit for table comments is 60 characters. That surprised me, since I had recently learned that was the limit before MySQL 5.5.3. I didn't find mention of what the field comment length restrictions were. Here are the comment length restrictions as I understand them: Field comments * 255 before before MySQL 5.5.3 * 1024 after MySQL 5.5.3 Table comments * 60 characters before MySQL 5.5.3 * 2048 characters after MySQL 5.5.3 I took a basic test SQL file and ran it on these versions of MySQL and MariaDB (Windows): * MariaDB 5.5.42 * MariaDB 10.0.17 * MySQL 5.5.42 (community edition) * MySQL 5.6.23 (community edition) and ended up with a test table and test field with max comment lengths of 2048 and 1024 characters respectively. Does the community maintain the KB article referenced earlier or does a member of the MariaDB team? Should I submit this as a bug report or is there a more appropriate action? Thanks.

2 2

[Maria-docs] Finding the right link to/from translated KB articles can be confusing
by Jean Weisbuch 20 Jan '15

20 Jan '15

I translated an article that is on this untranslated category (https://mariadb.com/kb/fr/mariadb/what-is-mariadb/) but i havent been able to use the usual ways to put links to other translated KB articles ("mariadb-vs-mysql-compatibility", "mariadb-vs-mysql-features" and "source-getting-the-mariadb-source-code") where the usual links of the form "fr/english-link" and "translated-link" doesnt works. I had to put the full URL (excluding "https://mariadb.com/kb/fr/") which are "mariadb/la-compatibilite-entre-mariadb-et-mysql", "mariadb/mariadb-vs-mysql-features/" and "mariadb/les-premiers-pas/obtenir-installer-et-actualiser-mariadb/comment-compiler-mariadb-a-partir-de-la-source/source-getting-the-mariadb-source-code/". What is the best practice here, i didnt find mentions about it on the documentation? Would it be possible to have by default links on translated articles to point to translated articles (when available) when the "default" URL (using the English KB page link without specifying the language) is used on the code ; having to check and fix almost every links when doing a translation is time consuming and could easily lead to mistakes. -- Another small issue : The documentation about translating KB pages (https://mariadb.com/kb/en/meta/translation-howto/) states that : "All translated articles must be placed in a translated category. If the translated parent does not exist, the article will be placed in the grandparent or root category. Please take the time to translate the parent category before translating any articles in that category.". But if i try to translate a category such as https://mariadb.com/kb/en/mariadb/faq/ i got an error message : "Sorry, you do not have permission to create an article here."

3 4

[Maria-docs] Having the possibility to have a per major release KB pages
by Jean Weisbuch 15 Jan '15

15 Jan '15

As 10.1 is on its way and has new features of its own and some others got deprecated, its getting a bit "complex" on some KB pages to have documentation for multiple major versions (eg. 5.1, 5.2, 5.3, 5.5, 10.0, 10.1, ...) on one page along with minor versions specifics (when changes got introduced after the first released version). A simple example (not the best one but its the page i was reading at the moment) : the SELECT statements documentation (https://mariadb.com/kb/en/mariadb/documentation/sql-structure-and-commands/…). The first part of the documentation is about the syntax but it only shows the 5.5 GA syntax, features added later must be found manually on the page and syntaxes deprecated after the 5.5 GA will have to be found manually too. It would be interesting to have the possibility to use a "generate per major release" flag on KB pages that would automatically generate subpages that are major-version specific with a switch between major release pages like on the MySQL documentation. For example, if a <<product mariadb from=10.0 to=10.0>> macro would be used (only using a major release version number or maybe by adding a "specific" flag to the macro to avoid mistakes), there would automatically be a 5.5 and a 10.0, 10.1 subpages (specified, previous and next releases) created where the content of the tag would only be shown on the 10.0 page (and on the "generic" page that shows every release infos such as its done at the moment). With that kind of automatic generation, it would be simpler to keep up to date documentation for every major release without having to create a specific page per major release or to display multiple <<product>> macros on one page while keeping it simple to manage (especially as there are also the translations to keep up). Having the possibility to set a from/to product version for a whole KB page could also be interesting to keep the browsing of the KB pages lighter if the user selected a specific MariaDB release, it could also be used to put automatically the info on top of the KB page in a clean way (example of how it is done actually : https://mariadb.com/kb/en/mariadb/documentation/managing-mariadb/optimizati…) and it could be of use for automatically generated documentation from the KB pages. These ideas are not perfect and i dont know if it would be simple to implement these on the KB code but the need for a solution for the problem will only keep growing.

2 1

[Maria-docs] suggestions on terminology
by Federico Razzoli 09 Jan '15

09 Jan '15

Hi! I think that we all agree that having a clear terminology is important, for example when explaining a problem or its possible solutions. However, there are at least 2 cases where I am not completely happy with the terminology used in MariaDB Docs. I will suggest some variations here - if a better solution is found, I will be happy to help editing the occurrences of those terms. * Virtual Columns The problem here is that VIRTUAL and PERSISTENT columns are both called virtual columns. Interestingly, one could say that virtual columns are a type of virtual columns :) Since VIRTUAL and PERSISTENT are keywords, the only solution is changing the general name. My suggestion is Calculated Columns (from SQL Server). * Dynamic Columns While this is a good term, there is not an "official" term to indicate the table column containing virtual columns. I suggest Dynamic Columns Set, or Container. * Procedure I never seen a "procedure" other than "procedure Analyze". But this feature exists, and its name is easely confused with Stored Procedures. I don't have a suggestion here (especially because PROCEDURE is a keyword). I hope that these suggestions will be useful. Regards, Federico

2 2

[Maria-docs] Usage of an informal tone on the documentation on the KB
by Jean Weisbuch 09 Jan '15

09 Jan '15

There are no details about what tone should be used on the KB pages (https://mariadb.com/kb/en/meta/contributing-to-the-mariadb-knowledge-base/) and many of the KB pages use an informal/personal tone with the use of the first (i, we) and second person (you) which i think doesn't suit very well for a enterprise-grade product documentation, at least it doesn't feels right when translating pages to French. Is that intentional or not and should there be a rule about that at least on documentation pages?

3 2

[Maria-docs] KB security bug: History pages have a XSS vulnerability
by 100の人 20 Dec '14

20 Dec '14

I think that history pages in MariaDB Knowledge Base have a cross-site scripting vulnerability because special characters contained in link texts and revision comments are not escaped. For example, this page: https://mariadb.com/kb/en/meta/editing-help/creole-formatting/+history -- 100の人

1 0

[Maria-docs] doubt about communication channels
by Roberto Spadim 02 Dec '14

02 Dec '14

hi guys, at https://mariadb.com/kb/en/mariadb/community/community-contributing-to-the-m… , we have: - participate in e-mail discussions via our Launchpad lists (whichever list is most appropriate): - maria-developers <http://launchpad.net/~maria-developers> - maria-discuss <http://launchpad.net/~maria-discuss> - maria-docs <http://launchpad.net/~maria-docs> but what is "whichever list is most appropriate", in other words, could we include some examples of what is expected in each mail list? for example, maria-docs about including, editing, removing docs from kb?! maria-developers talk about mdev development (i don't know how to use maria-developers, i some time sent wrong mail), etc... just one example at the end of this docs, i found how to use mraia-developers (i never read it before...) Where are the Developers? - Most of the core developers hang out on IRC <https://mariadb.com/kb/en/irc/> in the *#maria* channel on - freenode*.* - Code, proposals, and feature requests are sent to (and discussed on) the maria-developers list <http://launchpad.net/~maria-developers>. should be interesting write a "community guide" or something like it? i many times use jira as 'chat' to ask question (sorry), today elena told me to don't chat there, but i don't know if i should use maria-developer or maria-discus or irc :/ any idea? i don -- Roberto Spadim SPAEmpresarial Eng. Automação e Controle

2 2

[Maria-docs] table_definition_cache on mariadb.com
by Mike Griffin 29 Nov '14

29 Nov '14

https://mariadb.com/kb/en/mariadb/documentation/optimization-and-tuning/sys… Default Value: 400 Range: 400 to 64524288 In the code: VALID_RANGE(TABLE_DEF_CACHE_MIN, 512*1024), For MySQL: http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_… Default 400 Min Value 400 Max Value 524288

2 1

Re: [Maria-docs] [Maria-discuss] transactions and UNLOCK TABLES
by Roberto Spadim 23 Sep '14

23 Sep '14

this don't work too: LOCK TABLE t WRITE; BEGIN; SELECT @@in_transaction; (return 1) UNLOCK TABLES; SELECT @@in_transaction; (return 1) maybe a wrong documentation 'bug'

1 1

[Maria-docs] query cache at askmonty kb
by Roberto Spadim 22 Sep '14

22 Sep '14

Hi guys first, thanks greenman to review query cache article well i have some others doubts at query cache that i think should/could be better explained 1) Limitations - The query cache needs to be disabled in order to use OQGRAPH <https://mariadb.com/kb/en/oqgraph/> and, in older versions, Galera <https://mariadb.com/kb/en/galera/>. - The query cache is not used by the Spider <https://mariadb.com/kb/en/spider/> storage engine (amongst others). why qc must be disabled with oqgraph? what's the possible problems without disabling it? maybe examples are wellcome, since reading oqgraph information we only have: Installing See Installing OQGRAPH <https://mariadb.com/kb/en/installing-oqgraph/>. Note that the query cache <https://mariadb.com/kb/en/query-cache/> needs to be disabled for OQGRAPH to function correctly. Spider have some sql_cache/sql_no_cache features, maybe should be nice a feature table about what engine support and how it support 2) include something related to query cache lock problems 2.1) write content lock while inserting new queries 2.2) global lock "quering" query cache before query execution 2.3) maybe we could include some benchmarks since today we have only the "it's a feature that must be disabled", but when use a read intensive database (like a wordpress or something like it) it could be enabled 2.4) maybe some explain about good pratices with query cache and without query cache i think that's all =) thanks again -- Roberto Spadim

2 1