| ../irclogs/#mantishelp.2009-05-19.log | ||
| --- scribe started --- | 00:00 | |
| markw | anyway to get the file uploads to go bigger than 8M? | 04:29 |
|---|---|---|
| markw | php.ini set to 20M | 04:29 |
| markw | and the g_max_file_size or whatever is set to 20m. | 04:29 |
| markw | 20M. | 04:29 |
| mantisbot | New bug: Bug 10497 - Mr Papa - open - new | 06:22 |
| mantisbot | New bug: default version and target_version - http://www.mantisbt.org/bugs/view.php?id=10497 | 06:22 |
| mantisbot | New bug: Bug 10498 - mstedman - open - new | 06:27 |
| mantisbot | New bug: Allow search filter to include issues within "disabled" projects and their children - http://www.mantisbt.org/bugs/view.php?id=10498 | 06:27 |
| giallu | markw, which storage method? DB? | 06:37 |
| mantisbot | New bug: Bug 10499 - UmeshKhairnar - open - new | 06:42 |
| mantisbot | New bug: Published Exe's are throwing Exception on server - http://www.mantisbt.org/bugs/view.php?id=10499 | 06:42 |
| [KK]Kirill | hi all | 07:55 |
| [KK]Kirill | who use last git? | 07:56 |
| [KK]Kirill | what happend with datetime? | 08:01 |
| [KK]Kirill | I have date 01.01.1970 | 08:02 |
| mantisbot | New bug: Bug 10500 - mantistestor - open - new | 08:12 |
| mantisbot | New bug: Memo, Textarea, Multiline Customfields - http://www.mantisbt.org/bugs/view.php?id=10500 | 08:12 |
| giallu | uhm | 08:35 |
| [KK]Kirill | giallu: hi | 08:35 |
| giallu | database_version suddenly is 174 | 08:35 |
| giallu | hi [KK]Kirill | 08:36 |
| [KK]Kirill | Can you help me debug bad-date? | 08:36 |
| giallu | did you run the install.php upgrade steps? | 08:40 |
| [KK]Kirill | no :) | 08:43 |
| [KK]Kirill | Attempting to connect to database as user GOOD | 08:44 |
| [KK]Kirill | that's all | 08:44 |
| [KK]Kirill | sorry | 08:44 |
| [KK]Kirill | this line last | 08:44 |
| [KK]Kirill | it's ok? | 08:44 |
| [KK]Kirill | not - it's not ok | 08:47 |
| [KK]Kirill | I press upgrade, but not happend | 08:52 |
| [KK]Kirill | Checking Database Server Version | 08:52 |
| [KK]Kirill | Running mysql version 5.0.77 GOOD | 08:52 |
| [KK]Kirill | Installing Database | 08:52 |
| [KK]Kirill | that's all. | 08:52 |
| [KK]Kirill | giallu: ? | 09:10 |
| paulr_ | kirill: what database version is listed in select * from mantis_config_table where value = 'database_version' | 09:10 |
| [KK]Kirill | empty value | 09:11 |
| [KK]Kirill | 0 row | 09:12 |
| [KK]Kirill | hi paulr | 09:12 |
| * paulr_ wonders if he spelt it wrong | 09:12 | |
| paulr_ | just do select * from mantis_config_Table and find the db version :P | 09:12 |
| [KK]Kirill | 83 | 09:13 |
| [KK]Kirill | where config_id = 'database_version' | 09:13 |
| paulr_ | that's out of date then | 09:15 |
| paulr_ | install.php? | 09:15 |
| paulr_ | in fact 83 is out of date before my changes | 09:15 |
| paulr_ | git trunk was on 86 | 09:15 |
| [KK]Kirill | try /admin/install.php | 09:15 |
| [KK]Kirill | Attempting to connect to database as user GOOD | 09:16 |
| [KK]Kirill | Checking Database Server Version | 09:16 |
| [KK]Kirill | Running mysql version 5.0.77 GOOD | 09:16 |
| [KK]Kirill | Installing Database | 09:16 |
| [KK]Kirill | that's all | 09:16 |
| [KK]Kirill | one sec | 09:17 |
| [KK]Kirill | I think it's my mistake | 09:20 |
| [KK]Kirill | it's normal SYSTEM WARNING: htmlentities() expects parameter 1 to be string, array given ? | 09:22 |
| [KK]Kirill | *rofl* Your database has not been created yet. Please create the database, then install the tables and data using the information above before proceeding. | 09:22 |
| [KK]Kirill | ok.. It's my one more mistake | 09:25 |
| [KK]Kirill | Yes.. all work | 09:26 |
| [KK]Kirill | How I can correct some bad date? | 09:27 |
| [KK]Kirill | paulr: Thanks | 09:35 |
| [KK]Kirill | paulr: How I can use Firephp for debug? | 09:42 |
| [KK]Kirill | or it's only for events witch I write in config_inc.php? | 09:43 |
| Raging_Hog | How can I persuade my colleagues to use mantis instead of trac? What I've found out, it seems like trac doesn't have relationships between issues, ability to change statuses of many issues easily and you have to dig more to get a custom query | 09:44 |
| Raging_Hog | But, trac does import CSV files. I couldn't get mantis to import anything even with wget | 09:48 |
| paulr_ | [KK]Kirill: so you've fixed the date stuff? | 10:07 |
| Raging_Hog | version 1.1.6, I can't put issues on roadmap. I specify a target version, the issue has a priority, is new or assigned and has severity and reproducibility. Clicking on the roadmap-link just shows the empty page like when clicked on empty changelog. Should I do something else? | 10:15 |
| [KK]Kirill | paulr_: yes | 10:23 |
| [KK]Kirill | paulr_: thanks | 10:23 |
| [KK]Kirill | I copy/past last date value to fields where value equal 1 | 10:24 |
| paulr_ | erm | 10:33 |
| paulr_ | did you have to do that manually???? | 10:33 |
| [KK]Kirill | yes | 10:33 |
| [KK]Kirill | with phpmyadmin | 10:33 |
| paulr_ | sorry, what was the initial value before you modified? | 10:33 |
| [KK]Kirill | 01.01.1970 | 10:34 |
| [KK]Kirill | after upgrade 1 | 10:34 |
| [KK]Kirill | it's because I have renamed admin folder | 10:34 |
| paulr_ | so the upgrade set it to 1? | 10:37 |
| paulr_ | or what ;/ | 10:37 |
| [KK]Kirill | paulr_: datefield afer upgrade has value 1. | 10:53 |
| paulr_ | ok so that's fine | 10:53 |
| [KK]Kirill | I change it to value from last correct issue | 10:53 |
| paulr_ | 1 is correct for fields that haven't been used | 10:54 |
| [KK]Kirill | yes | 10:54 |
| * paulr_ doesnt' get what needed changing? | 10:55 | |
| [KK]Kirill | paulr_: nothing.. i haven't problem.. for now after upgrade I delete admin folder, before I upload new admin-folder | 11:04 |
| mantisbot | New bug: Bug 10501 - informatyk - open - new | 13:54 |
| mantisbot | New bug: It takes about 25seconds to load the login_page.php - http://www.mantisbt.org/bugs/view.php?id=10501 | 13:54 |
| DirtyAl | hello | 14:59 |
| DirtyAl | need some help with the mantis SVN integration | 14:59 |
| DirtyAl | have done alllisted in http://leetcode.net/blog/2009/01/integrating-git-svn-with-mantisbt/ | 14:59 |
| DirtyAl | I just need some tips on how ti reflect commits done in SVN in mantis | 15:00 |
| DirtyAl | how to I use the post-commit script | 15:00 |
| DirtyAl | tks | 15:00 |
| paulr_ | DirtyAl: nuclear_eclipse who wrote that normally lurks around this time of day | 15:20 |
| DirtyAl | tks, I think paulr_, lets see if nuclear_eclipse can help me | 16:00 |
| markw_ | heh, fell out of the buffer. Looking at increasing file upload size. php.ini set to 20M, LimitRequestBody set to 20971520, and storage is on disk. "report issue" page says 8,000k max attachment. | 16:35 |
| markw_ | where is it coming up with the 8,000k limit when I'm trying to allow 20M? | 16:38 |
| paulr_ | a) I think there might be a max file size in config.inc.php or whatever | 16:48 |
| paulr_ | b) mysql limit? | 16:48 |
| paulr_ | bbiab | 16:48 |
| DirtyAl | I need some help on how o use the post-commit script from the SourceWebSVN plugin | 16:50 |
| DirtyAl | tks | 16:50 |
| markw_ | paulr: I set max_file_size in confi.inc.php to 20971520 and went to disk storage. | 16:59 |
| markw_ | ha, found it. max_post_size. | 17:04 |
| DirtyAl | has anyone seen this messages? | 17:28 |
| DirtyAl | APPLICATION WARNING #2400: Event "EVENT_ACCOUNT_PREF_UPDATE_FORM" has not yet been declared.APPLICATION WARNING #2400: Event "EVENT_ACCOUNT_PREF_UPDATE" has not yet been declared. | 17:28 |
| DirtyAl | after installing the SVN/mantis integration plugins? | 17:28 |
| DirtyAl | I manage the post-commit script | 17:53 |
| DirtyAl | it is updating the changesets on mantis | 17:54 |
| DirtyAl | but it is not closing the tickets | 17:54 |
| DirtyAl | any help on this matter | 17:54 |
| DirtyAl | ? | 17:54 |
| DirtyAl | hello? anyone on the channel? | 17:56 |
| paulr | moo | 18:01 |
| DirtyAl | hehehe | 18:05 |
| nuclear_eclipse | DirtyAl: you need to be running Mantis from latest Git, or a nightly build | 18:16 |
| DirtyAl | hummm.... tks, I am running 1.2a3, I am seeing the repos, managing them, the tickets dont get automaclty fixed by commit | 18:18 |
| DirtyAl | i will download the nighly build right now, tks. | 18:19 |
| DirtyAl | then I just list the ticket number in the commit message like this #445 and the ticket will be closed and the commit message attached? | 18:21 |
| * thraxisp slaps paulr with a large trout | 18:22 | |
| thraxisp | What's up with changing dates to integers? | 18:23 |
| nuclear_eclipse | DirtyAl: you need to enable auto-resolving of issues in the source-integration configuration page before it will do that | 18:25 |
| nuclear_eclipse | thraxisp: it's so that we can actually start handling dates and timezones without dealing with the many stupid ways that DB's handle datetime values... | 18:26 |
| nuclear_eclipse | I'm not sure that I agree with the move to integers, but if it gets paulr to actually *fix* something.... | 18:26 |
| DirtyAl | Thk nuclear, I already did, but it is no doing so,I guess because I am not using the nighly build. | 18:28 |
| paulr | erm iirc int's was what you / victor agreed on ;/ | 18:28 |
| * paulr slaps nuclear_eclipse thraxisp | 18:29 | |
| nuclear_eclipse | I think most of what you're doing could have been done using the existing datetime schema, which would have made upgrades much more straightforward, but I also agree that using ints instead probably makes the code much simpler; it's always a tradeoff | 18:30 |
| paulr | it certainly speeds up code a little | 18:30 |
| nuclear_eclipse | DirtyAl: also make sure that a) your commit comments are matching the patterns for fixed issues, as opposed to simply linked issues, b) that your mantis username matches your SVN username or that you specify your SVN username in your account prefs | 18:34 |
| * paulr stares at nuclear_eclipse a bit more | 18:35 | |
| * nuclear_eclipse ignores paulr | 18:35 | |
| paulr | anyway, our handling of datetime | 18:36 |
| paulr | goes as much as: | 18:36 |
| paulr | store datetime in db | 18:36 |
| paulr | retrieve datetime from db as string | 18:36 |
| paulr | convert string to integer | 18:36 |
| paulr | use integer | 18:36 |
| nuclear_eclipse | DirtyAl: I recommend for the time being that you grab a nightly snapshot built from before the weekend, or grab a snapshot from git on the renamed-libraries-1.2.x tag :P | 18:37 |
| nuclear_eclipse | paulr: I'm not really sure why we couldn't just continue using that approach for compatibility reasons and to prevent the need for a whole lot of goofy schema-upgrading business.... | 18:38 |
| paulr | it was hardly compatible | 18:39 |
| nuclear_eclipse | well, I meant "compatible" in the sense that it didn't require a gigantic set of schema changes that could potentially break an upgrade... | 18:39 |
| paulr | bug 7974 | 18:39 |
| mantisbot | Bug 7974 - obouillaud - open - acknowledged | 18:39 |
| mantisbot | Date problem on french MSSQL - http://www.mantisbt.org/bugs/view.php?id=7974 | 18:39 |
| paulr | well | 18:40 |
| paulr | we need to decide quickly if we're now changing our mind on approach | 18:41 |
| DirtyAl | nuclear_eclipse: its working like a charm | 18:45 |
| DirtyAl | tks for the help | 18:45 |
| DirtyAl | great software | 18:45 |
| nuclear_eclipse | DirtyAl: you're welcome, and thank you :) | 18:45 |
| paulr | so what are you actually saying you want to do john ? :P | 18:46 |
| nuclear_eclipse | dunno | 18:47 |
| paulr | useful ;p | 18:48 |
| paulr | but seriously, one of the 'issues' with datetime in db and supporting oracle/postgres/mssql/the rest | 18:48 |
| paulr | is we are passing strings to db | 18:48 |
| paulr | getting a string back | 18:48 |
| nuclear_eclipse | using integers for dates is nicer/better; my only real complaint about it is the sheer amount of schema upgrades required to make that change | 18:48 |
| paulr | converting the string to an int before using | 18:48 |
| * paulr nods | 18:48 | |
| nuclear_eclipse | which is why I don't have a really strong opinion either way; they both have advantages and tradeoffs | 18:49 |
| paulr | I think there's still some work to do/review on int's (within mantis) | 18:49 |
| paulr | as you know my timezone is +0, which makes it somewhat more difficult to easily test stuff | 18:50 |
| paulr | i'm planning to have a review over next day or two to see what's left/wrong if anything | 18:50 |
| markw_ | hey, I noticed something when playing with the DISK file attachments. | 18:53 |
| nuclear_eclipse | you're still welcome to have an account on my server to test in a -500 timezone... | 18:53 |
| markw_ | you can't have duplicate filenames in the directory. | 18:53 |
| markw_ | so if someone uploads an attachment called logfile.txt it appears that it will try to save it over an existing logfile.txt | 18:56 |
| markw_ | for separate bugs. | 18:56 |
| DirtyAl | nuclear_eclipse:mantis sends emails on each update on a ticket | 19:04 |
| DirtyAl | via SVN, is does't | 19:04 |
| DirtyAl | coudl this be done? | 19:04 |
| thraxisp | paulr: using ints makes the db impossible to read or debug. | 19:04 |
| paulr | not really... | 19:05 |
| paulr | mysql you'd just do select from_unixtime() or whatever | 19:05 |
| thraxisp | but using the MySQL Admin tool is now useless. | 19:07 |
| nuclear_eclipse | DirtyAl: potentially, yes; I just haven't gotten the chance to implement something of that sort | 19:07 |
| thraxisp | quick. when is 12345922849 | 19:07 |
| nuclear_eclipse | duh, thraxisp, that's so obvious, I'm not even going to answer you :P | 19:08 |
| DirtyAl | nuclear_eclipse: tks, for now I will make the commit from SVN to send emails, it will do | 19:08 |
| thraxisp | paulr: I'm sure that every other php based package in the world that does time zones doesn't store times as ints. | 19:12 |
| paulr | I'm assuming you didn't mean 12345922849 | 19:20 |
| paulr | anyway, //echo $asctime(<timestamp>) in mirc is quite a quick way to answer that question | 19:20 |
| paulr | as is select from_unixtime(x) | 19:20 |
| paulr | iirc, when I last looked things vary | 19:21 |
| paulr | your thinking just mysql here | 19:21 |
| paulr | the first thing we spend time doing with the old code is converting a date string to an int | 19:22 |
| paulr | we then use the int internally | 19:26 |
| paulr | and if we are putting int back into db convert it to a string for the insert | 19:26 |
| thraxisp | Not really. I can only think of a few places where an int is needed. | 19:27 |
| paulr | by default we convert it to an int | 19:27 |
| paulr | within the api | 19:27 |
| thraxisp | But it's readable in the database as a timestamp. | 19:27 |
| paulr | you need to get the datetime from a string to an int for us to then print it as a date | 19:28 |
| paulr | maybe i'm missing something here but | 19:28 |
| paulr | you spend hours reading the db? :) | 19:28 |
| thraxisp | You are making it impossible to find a bug created yesterday in a database dump or via the db admin tools. | 19:28 |
| thraxisp | I have when debugging an issue. | 19:28 |
| paulr | well, that depends on your db admin tool ofc... | 19:29 |
| thraxisp | I also have used other packages that store dates as ints and waste hours converting to see what actually happened. | 19:29 |
| * paulr nods | 19:29 | |
| thraxisp | The MyQSL tools cone to mind | 19:29 |
| thraxisp | ^cone^come | 19:29 |
| paulr | but even so our standard behaviour | 19:30 |
| paulr | before this change was | 19:30 |
| paulr | whenever we load a date from db, convert it to an int for use in php | 19:30 |
| thraxisp | That is fine because it's hidden. There is no reason to corrupt the database because of a 0.01% performance improvement. | 19:31 |
| paulr | for example: http://git.mantisbt.org/?p=mantisbt.git;a=blob;f=core/history_api.php;h=c7f36edbea4de58aa3977d7ca3d7d3cec91f1b2e;hb=master-1.1.x | 19:31 |
| paulr | function history_get_raw_events_array( $p_bug_id, $p_user_id = null ) { | 19:31 |
| paulr | $raw_history[$j]['date'] = db_unixtimestamp( $v_date_modified ); | 19:31 |
| paulr | for each result | 19:31 |
| paulr | but i'm wondering a bit here... | 19:32 |
| paulr | lets say we reverted this commit | 19:32 |
| paulr | if I have a mysql server in germany atm | 19:33 |
| paulr | and I want to move it to the UK (different timezone) | 19:33 |
| paulr | atm, in mysql with datetime, we store dates as UTC? | 19:33 |
| paulr | My reasoning for changing was a few issues | 19:34 |
| thraxisp | Personally, I'd read the server timezone from the host, and have a user timezone. I would use the difference for display purposes. The database would be the server time. | 19:35 |
| paulr | a) we've got some bugs against mssql that you can configure mssql to handle dates as either MDY or DMY (whichever it should be) | 19:35 |
| thraxisp | This assumes that moving the server is rare. Even so, it takes a few SQL commands to update all of the timestamps. | 19:35 |
| paulr | I'm not quite sure how we detect in php what collation dates are stored in in db all the time | 19:35 |
| paulr | b) duedate's stuff is broken | 19:36 |
| paulr | as the calendar code is using utc/gmt/whatever | 19:36 |
| paulr | the database code is using something else | 19:36 |
| paulr | and php/adodb are trying to convert it to an int | 19:36 |
| paulr | and we're trying to compare int's at the end | 19:36 |
| paulr | c) regarding the database | 19:37 |
| paulr | surely, if you were going to pull a timestamp from db | 19:37 |
| paulr | and localise it | 19:37 |
| paulr | you'd need to have db returning stuff without a timedifference applied | 19:37 |
| paulr | (or at least parsing it like that) | 19:37 |
| paulr | I dont mind that much whether we store dates or int's in db | 19:38 |
| paulr | but trying to worko ut how mssql/pgsql/oracle/whatever else people ask about | 19:38 |
| paulr | handle dates | 19:38 |
| paulr | and the fact that the adodb library generates a warning in it's date routines for every call (As it calls mktime() without a param) | 19:38 |
| paulr | actually was starting to add up to more of a performance issue | 19:39 |
| paulr | I'm kinda assuming that it's not an issue to store int's in a db, and gives us a slight performance increase, and should remove some headaches | 19:41 |
| paulr | on the basis that: | 19:41 |
| paulr | a) by default when we select a datetime from db, the first thing we *always* seem to do is to convert it to an int (summary api does that a few thousand times) | 19:41 |
| paulr | b) it's rare to look at a database in raw mysql format for a webapp - as if the web app is working, you wouldn't need to, if your debugging something, your likely to look at the php | 19:42 |
| ivan_htp | hey guys | 19:51 |
| ivan_htp | i'm trying to integrate dokuwiki with mantis, but the single sign on doesnt works.. could anybody help me? | 19:52 |
| thraxisp | You seem to have a penchant for optimizing the wrong things. Saving 1 or 2 C function calls won't make any real difference in real time. | 19:54 |
| thraxisp | I'm sure we're going to spend the next 6 months fixing everything that relates to dates. | 19:54 |
| paulr | the point of changing dates was to try to fix what's broken atm | 19:55 |
| thraxisp | but you need to think of all of the other things that you did/might break in the process. | 19:55 |
| * paulr nods | 19:55 | |
| paulr | that's why the branc has been around for a month or two | 19:56 |
| thraxisp | I have a few migration scripts that translate from other trackers. These are all toast now. | 19:56 |
| thraxisp | I assume you are going to fix them too. | 19:56 |
| paulr | I'm happy to fix anything i've broken. | 19:56 |
| paulr | similarly, i'm happy to remove the code if needbe | 19:57 |
| paulr | but we've been talking for ages on how to handle dates | 19:57 |
| thraxisp | But have you tested it fully? (The debian test plan comes to mind). | 20:03 |
| paulr | dhx/myself have - i'm planning to review/test it more this week | 20:04 |
| paulr | it's a shame you didn't pick up on the discussion(s) that lead to this patch | 20:06 |
| paulr | thraxisp: if you take the (rather biased) blog post at http://billauer.co.il/blog/2009/03/mysql-datetime-epoch-unix-time/ | 20:09 |
| paulr | they do: | 20:09 |
| paulr | SELECT * FROM stupid_date; | 20:09 |
| paulr | to get: | 20:09 |
| paulr | 2009-03-15 14:01:43 | 20:09 |
| paulr | my issue was: | 20:09 |
| paulr | (iirc at least) | 20:09 |
| paulr | you dont know the timestamp on that | 20:10 |
| thraxisp | I'm unhappy that the database is no longer readable. W should ROT13 the data as well. It just makes it hard to debug / fix anything. | 20:10 |
| paulr | I've noticed | 20:10 |
| paulr | but surely it's not that much harder to do: | 20:11 |
| paulr | SELECT FROM_UNIXTIME(last_updated) from mantis_bug_table | 20:11 |
| paulr | on the occassion that one needs to read the db | 20:11 |
| paulr | I think one of the issues here is | 20:11 |
| paulr | you use some gui? | 20:11 |
| paulr | whereas, in my case at least, I tend to just use the cmd line mysql command | 20:12 |
| thraxisp | The author has obviously never been a DBA. | 20:12 |
| paulr | so if i'm typing a query, adding 'from_unixtime' isn't that big a job | 20:12 |
| thraxisp | No, byt generally, it's select * from table where foo=1; | 20:13 |
| paulr | as I said it's a rather biased view :) | 20:13 |
| thraxisp | The date is now garbage. | 20:13 |
| paulr | nod, unless one explicity from time's it | 20:14 |
| paulr | but then, i'm looking at issues like http://www.mantisbt.org/bugs/view.php?id=7974 | 20:15 |
| paulr | and due dates | 20:15 |
| paulr | part of the reasoning of converting to ints was to get rid of all the crap we've got going on to try to handle converting an int to a string to put it in a db | 20:17 |
| paulr | I'm pretty sure at one point of looking at fixing duedates I had a scenario that went along lines of: | 20:18 |
| paulr | java script calendar has date picker on | 20:18 |
| paulr | returns a string to php | 20:18 |
| paulr | php converts string to an int | 20:18 |
| paulr | database api converts into a string | 20:19 |
| paulr | <stored to db> | 20:19 |
| paulr | <retrieve from db> | 20:19 |
| paulr | convert string to int | 20:19 |
| paulr | convert int to string for jscript calendar | 20:19 |
| paulr | get string back from jscript calendar | 20:19 |
| paulr | and your 2 hours out | 20:19 |
| paulr | (Which just happens to be your timezone offset from gmt) | 20:20 |
| paulr | now, put that into the mix with user timezones that are seperate to database | 20:20 |
| paulr | I'm quite confident I can fix any things i've broken converting to ints in less time then it will to figure out that mess :) | 20:21 |
| thraxisp | We need to convert this stuff to OOP and hide the int date. | 20:30 |
| paulr | DateTime::createFromFormat( <int>, 'U' ); | 20:33 |
| paulr | is probably a sensible 'format' to throw around | 20:33 |
| paulr | s/format/object/ | 20:33 |
| paulr | anyway, part of my logic is I want to reduce reliance on adodb | 20:34 |
| paulr | (which was handling dates) | 20:34 |
| paulr | I appreciate it's a bit of a pain | 20:35 |
| paulr | I guess it also introduces the 2038 problem | 20:35 |
| paulr | but I think it should make some things easier | 20:35 |
| thraxisp | Is 2038 our next release? | 20:35 |
| thraxisp | :) | 20:35 |
| paulr | strings in different formats in different db's = headache | 20:35 |
| paulr | int's = well, we can be fairly sure what an int is :) | 20:35 |
| paulr | but when you've got users going I use mssql in french, and I need to run this custom query or modify DMY in adodb source to MDY to make it work | 20:36 |
| paulr | does strike me as hassle | 20:37 |
| paulr | (as i'm pretty sure if we changed DMY->MDY you'd break whichever half of the world was working before :) | 20:37 |
| thraxisp | I think you are trading off hours of admin time for a few ms or computer time. | 20:38 |
| thraxisp | We should read and write db date/time and convert to ints internally. | 20:39 |
| thraxisp | ^or^of | 20:39 |
| thraxisp | adodb should handle the differences between the databases. If it doesn't we should throw it out and use something better (PDO, Doctrine). | 20:40 |
| paulr | pdo doens't handle dates | 20:44 |
| paulr | * Obtain DBMS specific SQL code portion needed to declare an text type | 20:48 |
| paulr | * field to be used in statements like CREATE TABLE. | 20:48 |
| paulr | * | 20:48 |
| paulr | public function getNativeDeclaration($field) | 20:48 |
| paulr | case 'date': | 20:49 |
| paulr | return 'CHAR(' . strlen('YYYY-MM-DD') . ')'; | 20:49 |
| paulr | case 'time': | 20:49 |
| paulr | return 'CHAR(' . strlen('HH:MM:SS') . ')'; | 20:49 |
| paulr | case 'timestamp': | 20:49 |
| paulr | return 'CHAR(' . strlen('YYYY-MM-DD HH:MM:SS') . ')'; | 20:49 |
| paulr | so it seems that doctrine users char() for dates in mssql | 20:49 |
| paulr | date/datetime types in mysql | 20:49 |
| paulr | i.e. in short, if/when I find something better then adodb | 20:51 |
| paulr | I'll be the first to want to throw it out :) | 20:51 |
| paulr | the closest i've come so far is actually http://ezcomponents.org/ | 20:52 |
| thraxisp | I would worry that by the time we find something "better" we have forgotten how the code works. | 20:56 |
| thraxisp | The code, in many places, is obscure at best now. This just confuses it more. | 20:57 |
| paulr | the current stuff should make it less confusing gradually | 20:58 |
| thraxisp | except that dates aren't dates in the database. | 21:17 |
| mib_xd145v | hey - i wonder if anyone is doing things like needing to associate a client with a certain # of bugs for a given product | 21:33 |
| mib_xd145v | like a client is asking for features in your core application and you want to group by the clients requess... i imagine at this point you could use the wiki to mention the bug id's but any other ideas? | 21:34 |
| mantisbot | New bug: Bug 10502 - mclaus - open - new | 21:36 |
| mantisbot | New bug: Vraag om te doen - http://www.mantisbt.org/bugs/view.php?id=10502 | 21:36 |
| thraxisp | mib_xd145v: You could use a custom field to hold the client name if there is more than one reporter associated with the client. Or you can query by reporter, if there is only one user. | 21:45 |
| mib_xd145v | thraxisp: thx - I have done that in my existing 1.06 version but i think i stopped using it because i was concerned about the drop down getting a bit crazy on that field, but yeah, product with that field would do it wouldnt it. show only there items and still allow for the nice roadmap funciton for a product overall.. this is great software btw :) | 22:04 |
| mib_xd145v | i have been considering installing the newer stable build because of the roadmap aspect and wiki integration sounds nice as well. | 22:05 |
| mib_xd145v | i am a bit worried since 1.06 seems so stable - has the software become a little shaky with the new features or is the latest stable build a good bet? | 22:06 |
| paulr | what version are you thinking about? | 22:07 |
| mantisbot | New bug: Bug 10503 - misu - open - new | 22:11 |
| mantisbot | New bug: APPLICATION ERROR 0001303 when custom float field is left blank - http://www.mantisbt.org/bugs/view.php?id=10503 | 22:11 |
Generated by irclog2html.py