| ../irclogs/#mantishelp.2010-08-25.log | ||
| --- scribe started --- | 00:00 | |
| CIA-100 | Mantisbt: daryn * rd5a59a4cdebb /core/collapse_api.php: Fix missing space causing validation error. | 06:05 |
|---|---|---|
| CIA-100 | Mantisbt: daryn * r5dec982e75a1 /core/collapse_api.php: Remove extra \". | 06:05 |
| CIA-100 | Mantisbt: daryn * r6083666774c4 /core/html_api.php: Add missing closing tags. | 06:06 |
| CIA-100 | Mantisbt: daryn * re087425c4212 / (4 files in 4 dirs): Bug #11826 - Remove inline javascript for bug-jump field and put it in common.js. Add | 06:06 |
| foobot | Bug 11826 - dhx - open - assigned | 06:06 |
| foobot | Remove all inline JavaScript from MantisBT (use external scripts instead) - http://www.mantisbt.org/bugs/view.php?id=11826 | 06:06 |
| CIA-100 | Mantisbt: daryn * r94c2e872d0c0 /core/html_api.php: Use class rather than id for the menu links. They may appear more than once | 06:06 |
| CIA-100 | Mantisbt: daryn * r6b5e037ced1d / (4 files in 4 dirs): Bug #11826, Bug #11995, Fix invalid html in the view all bug filter. Add divs, classes and id's | 06:06 |
| foobot | Bug 11995 - brandonjackson - fixed - assigned | 06:06 |
| CIA-100 | Mantisbt: daryn * rc0d2239266ed / (core/print_api.php css/default.css): Move styles for recently-visited into css. remove html style elements. | 06:06 |
| CIA-100 | Mantisbt: daryn * r99a9d10435e7 /view_all_inc.php: remove border. It is not a valid tr attribute. | 06:06 |
| foobot | Add CSS IDs to html elements for styling and javascript access. - http://www.mantisbt.org/bugs/view.php?id=11995 | 06:06 |
| Github | mantisbt: master Daryn Warriner * d5a59a4 (1 files in 1 dirs): Fix missing space causing validation error. | 06:30 |
| Github | mantisbt: master Daryn Warriner * 5dec982 (1 files in 1 dirs): Remove extra \". | 06:30 |
| Github | mantisbt: master Daryn Warriner * 94c2e87 (1 files in 1 dirs): Use class rather than id for the menu links. They may appear more than once ... | 06:30 |
| Github | mantisbt: master Daryn Warriner * 6083666 (1 files in 1 dirs): Add missing closing tags. | 06:30 |
| Github | mantisbt: master Daryn Warriner * e087425 (4 files in 4 dirs): Bug #11826 - Remove inline javascript for bug-jump field and put it in common.js. Add ... | 06:30 |
| foobot | Bug 11826 - dhx - open - assigned | 06:30 |
| Github | mantisbt: master Daryn Warriner * c0d2239 (2 files in 2 dirs): Move styles for recently-visited into css. remove html style elements. | 06:30 |
| Github | mantisbt: master Daryn Warriner * 99a9d10 (1 files in 1 dirs): remove border. It is not a valid tr attribute. | 06:30 |
| Github | mantisbt: master Daryn Warriner * 6b5e037 (4 files in 4 dirs): Bug #11826, Bug #11995, Fix invalid html in the view all bug filter. Add divs, classes and id's ... | 06:30 |
| Github | mantisbt: master commits 0e504c8...6b5e037 - http://bit.ly/angOFM | 06:30 |
| foobot | Remove all inline JavaScript from MantisBT (use external scripts instead) - http://www.mantisbt.org/bugs/view.php?id=11826 | 06:30 |
| foobot | Bug 11995 - brandonjackson - fixed - assigned | 06:30 |
| foobot | Add CSS IDs to html elements for styling and javascript access. - http://www.mantisbt.org/bugs/view.php?id=11995 | 06:30 |
| davidinc_ | hi | 08:31 |
| davidinc_ | still don't have an answer about ManTweet plugin? | 08:31 |
| istvanb | hello | 08:40 |
| istvanb | anybody who has experience with the summary graphs? | 08:40 |
| istvanb | I have some global categories (like: bug, feature etc) and also some custom made based on project (like: request credentials, request new users etc). | 08:42 |
| istvanb | When I go to the summary page categories subpage, only these custom categories show up and the global categories are not | 08:42 |
| josephross_ | I have a question if anyone is around | 10:59 |
| josephross_ | i have noticed some people have a irc mantis announcement feed | 10:59 |
| josephross_ | and was wondering how this was done | 10:59 |
| josephross_ | ive looked at the rss feed but it seems to only give the description | 11:00 |
| josephross_ | not new events | 11:00 |
| CIA-100 | Mantisbt: daryn * r839f1d68bc77 / (7 files in 5 dirs): Fix #6626 - Add text area custom field type. Add column to handle long | 20:10 |
| * paulr pokes daryn | 20:12 | |
| daryn | :) | 20:12 |
| daryn | i was tired of waiting | 20:12 |
| paulr | I do want to revert that and make sure we're doing something that works on all our db's | 20:13 |
| daryn | it shouldn't be a problem at all | 20:13 |
| paulr | well, we are adding 'text' why? | 20:13 |
| daryn | it's the same as every other text field in the db. | 20:14 |
| paulr | yes, which I think might cause problems having it in that table | 20:14 |
| daryn | no it wont | 20:14 |
| paulr | you've tested mssql? | 20:14 |
| daryn | no | 20:15 |
| daryn | but we've been talking about this for over a year now...maybe two and still no resolution | 20:15 |
| paulr | sure | 20:15 |
| paulr | but randomnly dumping a field in without testing it isn't a solution | 20:16 |
| daryn | it isn't random | 20:16 |
| paulr | sure it is - you've not tested it on mssql | 20:16 |
| daryn | mssql bah | 20:16 |
| paulr | personally | 20:16 |
| paulr | if we have a data type mssql supports | 20:16 |
| paulr | we dont need text/value | 20:16 |
| paulr | and can simplify that code | 20:17 |
| paulr | alternatively, we probably need a seperate table | 20:17 |
| paulr | like we do with bugtext stuff | 20:17 |
| daryn | why would it need a different table? | 20:17 |
| giallu | not that I care about mssql but | 20:18 |
| giallu | if we're breaking it that's not good. the question is | 20:18 |
| giallu | are we breaking it? | 20:18 |
| paulr | well | 20:19 |
| daryn | it shouldn't be breaking it. the only issue would be does it use too much disk space to have null value text fields | 20:19 |
| paulr | iirc, reason we wanted a seperate field for long text was for db's like mssql... | 20:19 |
| paulr | for mysql we could just use the existing value field | 20:19 |
| paulr | and change the data type | 20:19 |
| paulr | same goes for postgres | 20:19 |
| giallu | paulr, that was what, 5 years ago? | 20:20 |
| giallu | maybe mssql is better now | 20:20 |
| paulr | my point is | 20:20 |
| paulr | adding an extra column to a db table to support something in mssql | 20:20 |
| paulr | without testing it in mssql or looking at what mssql now supports | 20:20 |
| paulr | is a bit silly ;) | 20:20 |
| giallu | yeah, I'd much prefer we drop mssql :) | 20:21 |
| paulr | so either we revert that commit and test mssql | 20:21 |
| paulr | or we keep that commit | 20:21 |
| paulr | test mssql and decide if we can go back to just having one column | 20:21 |
| paulr | and run a migration script on the data | 20:21 |
| daryn | yes but i've asked this exact question on here multiple times and you've given me different answers. First I suggested we just change the field but you didn't want to do that. Then i suggested either a new table or a new field and couldn't get a straight answer on that. I don't have an mssql system and I'm not going to build one which is why i've asked paulr on multiple occasions to confirm this issue for me | 20:22 |
| daryn | this is a fairly frequently requested feature and this solution seems reasonable to me. | 20:23 |
| giallu | daryn, see. you've got the worng medium. avoid asking here about design decisions | 20:23 |
| giallu | mailing list has memory :) | 20:23 |
| daryn | we had a discussion on the mailing list too I believe. that was quite some time back though. | 20:23 |
| giallu | wow. I forgot about it... | 20:24 |
| giallu | and it's not we have that much discussions there | 20:24 |
| paulr | i'll revert that commit locally | 20:27 |
| paulr | fix the mssql stuff that dhx broke | 20:27 |
| paulr | then reapply the commit | 20:27 |
| daryn | sounds fabulous to me. my evil plan appears to be working | 20:27 |
| paulr | heh | 20:27 |
| paulr | I just wish out installer actaully worked ;p | 20:29 |
| daryn | works for me...what's the issue? | 20:29 |
| giallu | daryn, anyway, you have all my sympathy. this is the kind of things that spoiled my willingness to devote time on stuff | 20:30 |
| paulr | giallu: well, it just requires testing | 20:31 |
| daryn | :) well, i figured i'd get a rise out of paulr by just committing it. surprised it took him 2 minutes to respond | 20:31 |
| paulr | and to commit db schema changes without testing | 20:31 |
| paulr | screws us over as we can't reverse them | 20:31 |
| paulr | i.e. to reverse this commit now if we decide we dont need it | 20:32 |
| paulr | we need to migrate data to old column | 20:32 |
| paulr | then delete the new column | 20:32 |
| paulr | or just delete the new column (and hope no one starts following trunk) | 20:33 |
| daryn | that should only be true if we released with it in and then reversed it. | 20:33 |
| paulr | dev's running test builds will get the schema change | 20:33 |
| paulr | and have their config updated | 20:33 |
| paulr | we can just delete the field | 20:33 |
| paulr | without caring about data (on basis it's not in a release) | 20:33 |
| paulr | but we can't delete schema changes back out | 20:34 |
| daryn | mm..why not? | 20:34 |
| paulr | when you update your db, it'll update config | 20:34 |
| paulr | so anyone running test instances | 20:34 |
| paulr | or dev's | 20:34 |
| daryn | right but test instances should be fresh every time anyway | 20:35 |
| paulr | sigh | 20:48 |
| daryn | paulr: yes? | 20:51 |
| paulr | array(6) { [0]=> string(16) "database_version" [1]=> string(1) "0" [2]=> string(1) "0" [3]=> string(1) "1" [4]=> string(2) "64" [5]=> string(2) "90" } | 20:55 |
| paulr | spot the flaw | 20:55 |
| paulr | daryn: seems adodb is broken :P | 21:02 |
| paulr | there's a surprise :) | 21:02 |
| daryn | what's broken? | 21:02 |
| paulr | the flaw | 21:02 |
| paulr | [10:02.28] <paulr> dary | 21:02 |
| paulr | array(6) { [0]=> string(16) "database_version" [1]=> string(1) "0" [2]=> string(1) "0" [3]=> string(1) "1" [4]=> string(2) "64" [5]=> string(2) "90" } | 21:02 |
| paulr | should be field names | 21:02 |
| paulr | not int's ;) | 21:02 |
| daryn | ah, yes we've run into that before | 21:03 |
| daryn | i think i switched from mysql to mysqli and it stopped doing that | 21:03 |
| daryn | for mysql was actually sending both numeric indexes and field names | 21:04 |
| daryn | So here appears to be the bad news: The text in row option will be removed in a future version of SQL Server. Avoid using this option in new development work, and plan to modify applications that currently use text in row. We recommend that you store large data by using the varchar(max), nvarchar(max), or varbinary(max) data types. To control in-row and out-of-row behavior of these data types, use the large value types out of r | 21:10 |
| daryn | ow option. | 21:10 |
| paulr | yes, I know | 21:14 |
| daryn | grr... | 21:15 |
| paulr | ? | 21:15 |
| daryn | just frustrating | 21:15 |
| paulr | why? :) | 21:15 |
| daryn | because i've asked this question several times and not gotten that answer. | 21:16 |
| paulr | we've pasted that text into here before ;p | 21:16 |
| daryn | i don't recall that one but whatever | 21:17 |
| paulr | paul__ntext, text, and image data types will be removed in a future version of Microsoft SQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.20:41 | 21:17 |
| paulr | darynyeah, i'm looking at that too... | 21:17 |
| paulr | :) | 21:17 |
| daryn | ok | 21:18 |
| paulr | anyway, issue is more, I can't get mssql to work at all atm | 21:18 |
| paulr | heh | 21:18 |
| paulr | we also need to decide if we support db2/oracle | 21:18 |
| paulr | as | 21:18 |
| daryn | doesn't matter for this issue really as we'll have a bunch of fields to change if that's the case | 21:18 |
| paulr | i've never managed to either of those db's set up in a way to dev with | 21:18 |
| paulr | tbh, i'm all for supporting just: a) mssql, b) pgsql, c) mysql d) sqlite | 21:19 |
| daryn | even the config value field is a longtext | 21:19 |
| paulr | (with sqlite being more for 'dev') | 21:19 |
| paulr | but the reason I dont like your commit is | 21:19 |
| paulr | the reason youv'e added it is because the custom field value is too short | 21:19 |
| daryn | right i get that but that's what i tried to fix before and you told me not to do that | 21:20 |
| paulr | if we conclude that we dont care about db2/oracle as no dev's can actually get it to run | 21:20 |
| daryn | making it one long field | 21:20 |
| paulr | yes | 21:20 |
| paulr | as converting varchar->text - with text you couldn't use it in same way in where clauses | 21:20 |
| daryn | so you're saying use varchar(max) for the value field and only have one field? | 21:23 |
| paulr | actually, i'm saying we need to work out wtf we support | 21:24 |
| paulr | :) | 21:24 |
| paulr | take db2 | 21:24 |
| paulr | as far as I understand | 21:24 |
| paulr | you can do varchar/long varchar up to 8000 chars or something | 21:24 |
| paulr | then need to use CLOB's | 21:24 |
| paulr | now you see | 21:26 |
| paulr | XL goes to 'TEXT' | 21:26 |
| daryn | right, and we have a bunch of 'XL' | 21:27 |
| paulr | at least some versions of mssql doesn't allow 'text' columns in a where clause or a group by clause | 21:27 |
| daryn | so this one field is not the issue | 21:27 |
| paulr | so | 21:29 |
| daryn | right..but text is going away in mssql anyway so who cares. we still have to figure out what to do with all the 'XL' fields | 21:29 |
| paulr | yes | 21:29 |
| paulr | but your only duplicating the value/text columns in the custom field table to deal with the mssql datatype issue | 21:29 |
| paulr | and I suspect your commit has probably just broken some sort of filtering in mssql | 21:30 |
| paulr | (or at least potentially has) | 21:30 |
| paulr | Personally, I want to drop db2/oracle support as afaict, NONE of the core dev's run it | 21:31 |
| daryn | i'm ok with that | 21:31 |
| paulr | and so far i've personally failed to install db2/oracle on windows | 21:31 |
| daryn | not that it matters | 21:31 |
| paulr | and get it to work properly | 21:31 |
| paulr | i'd then like to drop 'mssql' support | 21:32 |
| paulr | and add one or both of odbc_mssql and sqlsrv | 21:32 |
| paulr | and to do the above, we need to drop adodb | 21:33 |
| paulr | as people don't like us having to patch adodb | 21:33 |
| daryn | k. so how long is it going to take you to do that? | 21:36 |
| paulr | well, question is whether everyone agrees on the db2/oracle thing | 21:37 |
| paulr | for now at least | 21:37 |
| daryn | so...either way we need to not use text. if we keep mssql, it's deprecated. If we don't use mssql we don't need it, right? | 21:39 |
| paulr | db2/oracle I think need it | 21:39 |
| daryn | oh good grief | 21:39 |
| paulr | db2 has 8000 char limit on varchar | 21:39 |
| daryn | ew...looks like 4000 | 21:41 |
| paulr | php db2_* functions are part of pecl | 21:43 |
| paulr | Number of releases: 32 | 21:46 |
| paulr | Total downloads: 54,240 | 21:46 |
| paulr | so not that many people downloading it from pecl | 21:47 |
| daryn | you've got no argument from me against dropping db2 or oracle. I need to decide how to proceed with cf. It's a requested feature and one that I need. | 21:49 |
| daryn | so, if we keep mssql text won't work. if we keep oracle/db2 text has to work. so one or both of them have to go, right? | 21:51 |
| paulr | not necessarily | 21:53 |
| paulr | as we could adjust what adodb maps XL to for mssql | 21:53 |
| paulr | (which to all intents and purposes involves setting up our own datadict | 21:53 |
| daryn | ok... | 21:54 |
| daryn | so we can leave the field as XL until we decide what we're doing...then the question is why one field, two fields, or two separate tables is better | 21:55 |
| paulr | the answer of mssql(with varchar(max)), mysql and pgsql I believe is one field | 21:56 |
| paulr | with 2 fields/separate tables being historically better | 21:56 |
| paulr | for oracle/db2 no idea | 21:56 |
| paulr | http://richardlees.blogspot.com/2010/07/varcharmax-performance-in-sql-server.html | 21:57 |
| daryn | why though? just because we've always done it that way? is there really a performance difference? In this case you will always be selecting only the field with the value. the other field will be ignored. | 21:57 |
| daryn | does it still slow the query down or use more memory? | 21:57 |
| paulr | apparently: 1. Adding a Text Data type / Varchar (MAX) to a table removes the ability for online re-indexing | 21:59 |
| paulr | http://geekswithblogs.net/johnsPerfBlog/archive/2008/04/16/ntext-vs-nvarcharmax-in-sql-2005.aspx | 22:00 |
| paulr | By default NTEXT stores the text value in the LOB structure and the table structure just holds a pointer to the location in the LOB where the text lives. | 22:01 |
| paulr | Conversely, the default setting for NVARCHAR(MAX) is to store its text value in the table structure, unless the text is over 8,000 bytes at which point it behaves like an NTEXT and stores the text value in the LOB , and stores a pointer to the text in the table. | 22:01 |
| paulr | tbh, I thought that's what ntext did ;P | 22:01 |
| paulr | also see http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/4de94284-cfe2-4a47-9863-8a2bbce4fb07 | 22:03 |
| paulr | I guess the question is for us | 22:03 |
| daryn | blah | 22:03 |
| paulr | if you consider that most of our text fields are probably <8000 | 22:03 |
| paulr | whether nvarchar(max) is better for our workload :) | 22:03 |
| daryn | i think that would be a very assessment to make. I'd bet we have multiple custom fields with lots records > 8000 | 22:04 |
| paulr | well I was thinking bugnotes and whatever else we have as text | 22:05 |
| daryn | right | 22:05 |
| paulr | i.e. 8000 characters is probably about 1000 words | 22:05 |
| paulr | that's like a side or two of A4 right? :) | 22:05 |
| daryn | about 1600 words | 22:06 |
| daryn | no idea about A4 :P | 22:06 |
| daryn | maybe two sides. i'd agree way more than most fields will need | 22:06 |
| paulr | anyway... | 22:07 |
| paulr | coming back to where we were | 22:07 |
| paulr | we really need to decide on what we spport | 22:07 |
| paulr | so we can test it | 22:07 |
| paulr | properly ;) | 22:07 |
| paulr | moving from where we are now which is basically: | 22:08 |
| paulr | a) db2 | 22:08 |
| paulr | b) oci8 | 22:08 |
| paulr | c) mysql | 22:08 |
| paulr | d) mysqli | 22:08 |
| paulr | e) mssql | 22:08 |
| paulr | f) odbc_mssql | 22:08 |
| paulr | g) pgsql | 22:08 |
| paulr | to: | 22:08 |
| paulr | a) mysqli | 22:08 |
| paulr | b) sqlsrv | 22:08 |
| paulr | c) pgsql | 22:08 |
| paulr | d) sqlite | 22:08 |
| paulr | probably makes some sense | 22:08 |
| daryn | yeah... | 22:09 |
| paulr | (Although this MySQL extension is compatible with MySQL 4.1.0 and greater, it doesn't support the extra functionality that these versions provide. For that, use the MySQLi extension.) | 22:09 |
| paulr | (I assume mysql is gradually going to be deprecated in favour of mysqli | 22:10 |
| daryn | maybe why mysql was acting weird for me. | 22:10 |
| paulr | iirc, i remember a php dev mailing list discussion about whether they should make mysql_* functions point to mysqli_* ones | 22:10 |
| daryn | so...one field or two tables... | 22:11 |
| daryn | i like one field | 22:11 |
| paulr | Versions of PHP since 5.3.0 have MySQL support enabled as standard through the use of the mysql, mysqli, and PHP_PDO_MYSQL extensions. Each of these extensions now uses the MySQL Native Driver by default, rather than the MySQL Client Library, libmysql. | 22:12 |
| paulr | at one point i think mysqli was the native driver (might be wrong) | 22:13 |
| paulr | anyway | 22:13 |
| paulr | what I dont know | 22:14 |
| paulr | is whether we need both mysql+mysqli etc | 22:14 |
| paulr | but looking at my above list | 22:15 |
| paulr | it strikes me we'd dump a lot of old modules | 22:15 |
| paulr | use the newest | 22:15 |
| paulr | add spport for sqlite | 22:15 |
| paulr | and half the number of db's we support | 22:15 |
| paulr | making it semi-possible to test all 4 | 22:15 |
| daryn | so, my thought... 1) alter cf.value to Text? 2) install function to cp cf.text to cf.value 3) drop cf.text | 22:16 |
| daryn | we already have XL fields all over the place so if mssql is broken, it's already broken. then we can upgrade the field if necessary along with all the others | 22:17 |
| paulr | I don't really like the idea of having 'shorttext' custom field + 'longtext' (i.e. what we now have) | 22:17 |
| paulr | and then allowing users to specify a max length on short+long text | 22:17 |
| daryn | both shortext and longtext are variable in most cases so they only use what they use...why does it matter? | 22:18 |
| paulr | well if 'shorttext+longtext are both infinite length | 22:19 |
| paulr | confusing | 22:19 |
| paulr | in terms of db engines | 22:19 |
| paulr | NULL. The value is a NULL value. | 22:19 |
| paulr | INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value. | 22:19 |
| paulr | REAL. The value is a floating point value, stored as an 8-byte IEEE floating point number. | 22:19 |
| paulr | TEXT. The value is a text string, stored using the database encoding (UTF-8, UTF-16BE or UTF-16LE). | 22:19 |
| paulr | BLOB. The value is a blob of data, stored exactly as it was input. | 22:19 |
| paulr | Those are sqlite data types | 22:19 |
| daryn | i have to go pick up kids...i'll be back in about 45min - an hour. will you still be here? | 22:19 |
| paulr | i.e. | 22:19 |
| paulr | for the most part can be ignored | 22:19 |
| paulr | going to bed in 40m probably | 22:19 |
| paulr | so unlikely | 22:19 |
| paulr | anyway, if everyone's agreed on forgetting about db2/oracle for now | 22:20 |
| paulr | we can simplify code and decide | 22:20 |
| paulr | it also makes my life easier to replace db layer - as I can't get db2/oracle to work atm so kinda hard to write a dblayer for :P | 22:20 |
| paulr | enjoy the kids ;) | 22:20 |
| daryn | so, is my plan above ok with you? to simplify to one XL field for now? | 22:21 |
| daryn | and migrate rather than reverting since we 'have a db change out there'? | 22:21 |
| paulr | kinda want to think | 22:21 |
| daryn | you said that 6mos ago, yr ago...etc. I need to move! | 22:21 |
| paulr | originally, I believe we were thinking of using seperate db tables :) | 22:22 |
| daryn | we went back and forth | 22:22 |
| daryn | seems silly and more complicated to me | 22:22 |
| paulr | but that was partly because we were trying to support mysql 2, sql 7, pgsql 6 as well as mysql 6, mssql 2008 and pgsql 9 | 22:22 |
| paulr | :) | 22:22 |
| paulr | we are on 1.3 now | 22:22 |
| paulr | i'd be inclined for that to focus on | 22:23 |
| paulr | sql 2008 Express (Free) | 22:23 |
| daryn | which raises the text problem | 22:23 |
| paulr | pgsql 8 + 9 | 22:23 |
| paulr | and mysql 5 | 22:23 |
| daryn | k. so...one field | 22:23 |
| daryn | i want to do this tonight | 22:24 |
| paulr | well, we've not checked the mysql/pgsql docs in this discussion :) | 22:24 |
| daryn | mysql is fine | 22:24 |
| daryn | pgsql not sure | 22:24 |
| paulr | s a great time to beta test the 5.5 release and give feedback to the MySQL engineering team. | 22:24 |
| paulr | mm | 22:24 |
| daryn | but i'd go with fine | 22:24 |
| daryn | i'll look tonight | 22:24 |
| paulr | the biggest issue is queries | 22:24 |
| paulr | with text, that was where mssql hit grief | 22:25 |
| daryn | remembering that if we have to convert XL at all we have to do it anyway | 22:25 |
| paulr | i.e. you couldn't group by ntext | 22:25 |
| daryn | right | 22:25 |
| daryn | which you wouldn't normally want to do anyway | 22:25 |
| paulr | need to check if you can groupby varchar(7999) but not group by varchar(8001) | 22:25 |
| paulr | there was also something with WHERE clauses | 22:25 |
| daryn | although where '%xxx%' would be valuable | 22:25 |
| paulr | but then we've also rewritten filter api a bit | 22:26 |
| paulr | :) | 22:26 |
| daryn | and i read two items, one said you can't do it but didn't say which versions, the other said shouldn't do it under certain circumstances | 22:26 |
| daryn | gotta go...post additional thoughts you have and I'll read them in a bit | 22:26 |
| paulr | so yea | 22:26 |
| paulr | lo dhx | 22:26 |
| dhx_m | hey | 22:27 |
| paulr | www.mantisforge.org/irclogs | 22:27 |
| daryn | hi dhx_m read backlogs...i'll be back in an hour | 22:27 |
| paulr | read last hour pls | 22:27 |
| paulr | heh | 22:27 |
| * paulr strokes whip | 22:27 | |
| Github | mantisbt: master Daryn Warriner * 839f1d6 (7 files in 5 dirs): Fix #6626 - Add text area custom field type. Add column to handle long ... - http://bit.ly/aIcLnz | 22:30 |
| dhx_m | read it :) | 22:39 |
| dhx_m | my comment at the moment is to stick with the databases used by developers | 22:40 |
| dhx_m | -or- setup an automated testing service that tests branches against multiple databases | 22:40 |
| paulr | wb | 23:13 |
| paulr | (6) | 23:14 |
| daryn | hola | 23:16 |
| daryn | paulr so...thought about it? one field or two tables? | 23:18 |
| paulr | I think we are all agreed atm on supported db's | 23:18 |
| paulr | aka: | 23:19 |
| paulr | [11:08.28] <paulr> to: | 23:19 |
| paulr | [11:08.35] <paulr> a) mysqli | 23:19 |
| paulr | [11:08.41] <paulr> b) sqlsrv | 23:19 |
| paulr | [11:08.43] <paulr> c) pgsql | 23:19 |
| paulr | [11:08.45] <paulr> d) sqlite | 23:19 |
| paulr | so we should really make some notes on what those db's support/allow | 23:19 |
| paulr | and any obvious oddities | 23:19 |
| paulr | what storage engine do we use ? | 23:23 |
| paulr | myISAM? | 23:23 |
| daryn | yes | 23:24 |
| daryn | my point is we have a feature i've personally been waiting to push for about 2 years. the bug reference was from 2006 and XL is currently all over our db. So, to me, using an existing field type to push a long awaited feature and working out the kinks later makes sense. We're going to have to work them out in exactly the same manner anyway. | 23:25 |
| daryn | i'll concede that deciding whether to use 1 or 2 fields or 2 tables should have been nailed down first | 23:26 |
| paulr | Static format is the default for MyISAM tables. It is used when the table contains no variable-length columns (VARCHAR, VARBINARY, BLOB, or TEXT) | 23:26 |
| paulr | .. | 23:26 |
| paulr | Static-format tables have these characteristics: | 23:26 |
| paulr | CHAR and VARCHAR columns are space-padded to the specified column width, although the column type is not altered. | 23:26 |
| * paulr ponders | 23:26 | |
| paulr | surely that didn't mean to put and varchar there | 23:26 |
| paulr | anyway | 23:26 |
| paulr | Of the three MyISAM storage formats, static format is the simplest and most secure (least subject to corruption). It is also the fastest of the on-disk formats due to the ease with which rows in the data file can be found on disk: | 23:26 |
| paulr | now | 23:27 |
| paulr | I guess that means we dont have many(any?) static formats | 23:27 |
| daryn | unlikely | 23:27 |
| daryn | oh, bug relationship is | 23:28 |
| daryn | bug tag is | 23:29 |
| daryn | so, at least a couple | 23:29 |
| daryn | but mostly no | 23:29 |
| paulr | raises an interesting question of whether char() would ever be better then varchar() ;p | 23:35 |
| paulr | mysql> describe mantis_custom_field_string_table; | 23:35 |
| paulr | +----------+--------------+------+-----+---------+-------+ | 23:35 |
| paulr | | Field | Type | Null | Key | Default | Extra | | 23:35 |
| paulr | +----------+--------------+------+-----+---------+-------+ | 23:35 |
| paulr | | field_id | int(11) | NO | PRI | 0 | | | 23:35 |
| paulr | | bug_id | int(11) | NO | PRI | 0 | | | 23:36 |
| paulr | | value | varchar(255) | NO | | | | | 23:36 |
| paulr | +----------+--------------+------+-----+---------+-------+ | 23:36 |
| paulr | 3 rows in set (0.06 sec) | 23:36 |
| paulr | anyway | 23:36 |
| paulr | that table | 23:36 |
| paulr | I have a couple of opinions | 23:36 |
| paulr | a) we limited it to varchar() so as to not break mssql at one point - I know as I tested changing it | 23:36 |
| paulr | we've now changed it to text, so if it still breaks mysql with other customfield/filter changes | 23:37 |
| paulr | we've just broken it anyway | 23:37 |
| paulr | I partly wondering if we should have a mantis_custom_field_int_table | 23:37 |
| paulr | and a custom_field_string_table | 23:37 |
| daryn | now we're rewriting cf again... | 23:38 |
| paulr | as a lot of our custom fields are to indicte dropdowns/checkbxoes etc where outcome is int | 23:38 |
| paulr | :) | 23:38 |
| paulr | either way, I think having value+text is the wrong solution | 23:38 |
| paulr | as if it breaks mssql, it's gonna break it by having it there anyway | 23:39 |
| paulr | it seems we've already lost any mysql performance stuff | 23:39 |
| paulr | and iirc, pgsql stores short+long strings same way anyway | 23:40 |
| paulr | or does it on fly | 23:40 |
| daryn | my point is if text breaks mssql it's already broken | 23:40 |
| paulr | now considering you'll probably hit grief trying to convert text to varchar | 23:41 |
| paulr | i'd be half inclined to yank the commit | 23:41 |
| paulr | maximum size of varchar(max) is 2^30-1 | 23:42 |
| paulr | maximum size of ntext/text is 2^31-1 | 23:42 |
| paulr | so I wonder if you can do alter table text -> varchar | 23:42 |
| paulr | or whether sql will error/warn you heavily | 23:42 |
| daryn | this is why i asked you to test this stuff...i don't have facility to test against anything but mysql and pgsql | 23:43 |
| paulr | well, adodb will fail to do it as it's shit | 23:47 |
| paulr | but moving from text<>varchar's fine | 23:47 |
| paulr | doesn't need any casting etc | 23:47 |
| paulr | (at least not in the sql management studio) | 23:47 |
| paulr | however | 23:48 |
| paulr | right now I need to go to bed | 23:49 |
| daryn | you said that... | 23:49 |
| paulr | which bit? | 23:49 |
| daryn | go to bed | 23:49 |
| paulr | well it is 1am | 23:49 |
| daryn | i still don't know what i'm supposed to do... | 23:49 |
| paulr | undo the schema change in some way | 23:53 |
| paulr | heh | 23:53 |
| daryn | you want two tables or one? | 23:53 |
| paulr | one for ints, one for strings maybe? | 23:53 |
| daryn | what datatype for strings? | 23:53 |
| paulr | ^^ that would probably be most sensible setup for performance maybe depending on how it was used | 23:54 |
| paulr | XLNEW | 23:54 |
| daryn | where is that? i don't see it in the datadict | 23:54 |
| paulr | correct ) | 23:55 |
| paulr | it doesn't exist yet | 23:55 |
| daryn | uh...ok | 23:55 |
| paulr | need to take a sledge hammer to it | 23:55 |
| daryn | we don't have time for a sledgehammer right now | 23:56 |
| paulr | sure we do | 23:56 |
| paulr | well not this second as i'm going to bed but | 23:56 |
| daryn | not at the speed you move :P | 23:56 |
| paulr | you dont know how much I hate adodb :) | 23:56 |
| paulr | anyway, really need to go :P | 23:57 |
| daryn | so, i'm just going to split it out to two tables make one int the other... XL :P and you can change it later | 23:57 |
| paulr | (I'm assuming that two tables makes sense - as probably 50% of custom fields are gonna be checkboxes or whatever | 23:58 |
| daryn | k. two tables | 23:58 |
| daryn | int, XL | 23:58 |
| paulr | 'i'm just going to split it out ' | 23:58 |
| paulr | 'just' | 23:58 |
| paulr | you make it sound easy :) | 23:58 |
| daryn | it is | 23:58 |
| paulr | should be fun updating enum stuff and filters etc :P | 23:58 |
| paulr | and you now need to move int's from the current string values for enums etc | 23:59 |
| daryn | the enums are mostly just strings i think though... | 23:59 |
| paulr | surely we store int and then the string in the definition?? | 23:59 |
Generated by irclog2html.py