From: Damien R. <dr...@ma...> - 2013-09-14 23:12:29
Attachments:
update_mantisbt.org_bugs.sql
|
Hi I wanted to run an upgrade test from 1.2 to 1.3 on PostgreSQL. To have a more realistic case than upgrading an empty database, I decided to use a dump from our tracker, which I converted and imported. Running Mantis after that gave me a lot of SQL errors which made no sense in terms of the code I had modified, so I started looking in details and finally found out that the schema definition does not match a "standard" 1.2 fresh install. I noted (excluding plugin-specific tables): - 2 extra tables (mantis_tasks_table, mantis_upgrade_table) - 49 differences in indexes (extra, missing, different name, different definition, e.g. unique) - 130 column type differences, - 61 default values differences - 1 column which should be "not null" but is not I generated an SQL script (attached) by comparing the schemas to correct the differences, and executed it. As my script failed to create a missing unique index on username column, I uncovered 2 cases of duplicate keys in mantis_user_table, (users 'updater', 2 records, and 'dmok', 3 records). After carefully checking that these accounts were not referenced anywhere in the database, I deleted the extra records (keeping only the one that was created first). Then I carefully compared the reference schema with the updated ones, and found no further differences in tables or indexes definitions. Unless someone objects, I would like to run this script on the official tracker to align the schema to "standard". Note regarding the 2 extra tables (that would be dropped by my script): - mantis_upgrade_table contains an upgrade_id (mantis version + sequence number) and a text description of the change - mantis_tasks_table: contains just test data created in 2001 These are possibly leftovers from an earlier (very old) version of Mantis, I don't know, but I don't think there is any value in keeping that. Let me know your thoughts Damien |
From: Paul R. <pa...@ma...> - 2013-09-15 00:23:16
|
You don't actually say what current schema is - however, I'd be inclined to be against manually running a script. Our bug tracker is oldest tracker we have that's been updated through all releases. Therefore, if that doesn't match, we need to investigate why for each instance where it is different. In terms of mantis_tasks_table - that's never been in mantis core - therefore that could be dropped. In terms of mantis_upgrade_table - that used to be part of mantis prior to the move to the current installer methodology, and therefore should remain. [We need to decide whether we add a database update to mantis to look to delete the mantis_upgrade_table if it exists] On Sun, Sep 15, 2013 at 12:12 AM, Damien Regad <dr...@ma...> wrote: > Hi > > I wanted to run an upgrade test from 1.2 to 1.3 on PostgreSQL. To have a > more realistic case than upgrading an empty database, I decided to use a > dump from our tracker, which I converted and imported. > > Running Mantis after that gave me a lot of SQL errors which made no sense > in terms of the code I had modified, so I started looking in details and > finally found out that the schema definition does not match a "standard" > 1.2 fresh install. > > I noted (excluding plugin-specific tables): > - 2 extra tables (mantis_tasks_table, mantis_upgrade_table) > - 49 differences in indexes (extra, missing, different name, different > definition, e.g. unique) > - 130 column type differences, > - 61 default values differences > - 1 column which should be "not null" but is not > > I generated an SQL script (attached) by comparing the schemas to correct > the differences, and executed it. > > As my script failed to create a missing unique index on username column, I > uncovered 2 cases of duplicate keys in mantis_user_table, (users > 'updater', 2 records, and 'dmok', 3 records). After carefully checking that > these accounts were not referenced anywhere in the database, I deleted the > extra records (keeping only the one that was created first). > > Then I carefully compared the reference schema with the updated ones, and > found no further differences in tables or indexes definitions. > > Unless someone objects, I would like to run this script on the official > tracker to align the schema to "standard". > > Note regarding the 2 extra tables (that would be dropped by my script): > - mantis_upgrade_table contains an upgrade_id (mantis version + sequence > number) and a text description of the change > - mantis_tasks_table: contains just test data created in 2001 > These are possibly leftovers from an earlier (very old) version of Mantis, > I don't know, but I don't think there is any value in keeping that. > > Let me know your thoughts > Damien > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |
From: Damien R. <dr...@ma...> - 2013-09-16 08:39:29
Attachments:
diff.log
|
On 2013-09-15 02:23, Paul Richards wrote: Hi Paul, and thanks for the feedback. > You don't actually say what current schema is I assume you are referring to actual schema differences, since the schemas are obviously both on version 183. Attached is the log file showing details of the comparisons. For more info on how this was generated, please see the wiki page where I documented the process [1]. [1] http://www.mantisbt.org/wiki/doku.php/mantisbt:schema_compare_update > - however, I'd be inclined > to be against manually running a script. Our bug tracker is oldest > tracker we have that's been updated through all releases.. Therefore, if > that doesn't match, we need to investigate why for each instance where > it is different. Fair enough, however that is not a justification for keeping a potentially incorrect schema around. We can always keep a backup of the current database for historical purposes before the fix. I was not around in the pre 1.0 days, but I believe upgrades were executed by manually running SQL scripts. I would therefore argue that differences such as: - columns of VARCHAR type that are expected to be INTEGER (or some variant of it) - columns of smaller size, e.g. number(7) vs number(10), text vs longtext - incorrect default values - missing unique index on mantis_user_table.username are the result of missing, wrong or improperly executed upgrade steps, which could potentially lead to bugs. > In terms of mantis_tasks_table - that's never been in mantis core - > therefore that could be dropped. OK > In terms of mantis_upgrade_table - that used to be part of mantis prior > to the move to the current installer methodology, and therefore should > remain. [We need to decide whether we add a database update to mantis to > look to delete the mantis_upgrade_table if it exists] Good point, I updated the script to skip this table. That said, if the table serves no purpose once the instance has been upgraded to 1.0.x or later as you seem to imply (in fact the only reference to it in the source is a check in the login page), then I recommend we do add the upgrade step to drop it in schema.php. Damien |
From: Paul R. <pa...@ma...> - 2013-09-16 20:16:56
|
Right, The number(7) vs number(10) is caused the our migration to adodb. Basically, historically we set INT(7) as data type, with an auto/zero fill so the number returned from db was 000023 or similar. When we then looked at other databases, that filling was moved into the PHP code I believe. At the same time, with the move to adodb, we stopped specifying the length field e.g. (7)/(10), hence the difference. In terms of mysql, the (7)/(10) represents the display width of a column if zero fill is enabled, and does not alter the size of the data field - it's 4 bytes in both case. Therefore this doesn't actually make any difference, and we can just ignore In terms of the text vs longtext, I'm half inclined to think that our database ( the non-12 one) probably has it correct for some fields at least: a) text = 75KB b) mediumtext = 16MB c) longtext = 4GB Allowing 4GB for a token for instance seems rather silly. For a bug description, I could imagine you *could* hit the 75KB limit, but.... For the remaining two issues: - incorrect default values ^ I'm inclined to look back at this with a view to adding a database check for mysql only to fix this on old datasets. As we can probably add a fix for this fairly easily. - missing unique index on mantis_user_table.username ^ I'd say that's worth manually running against the database - the index should be there as you say, and that's in the script. If I had to make a guess, there is/was a duplicate username, therefore the index part of the upgrade wouldn't apply, and instead of someone fixing that, they've just skipped the index. Paul > - however, I'd be inclined >> to be against manually running a script. Our bug tracker is oldest >> tracker we have that's been updated through all releases.. Therefore, if >> >> that doesn't match, we need to investigate why for each instance where >> it is different. >> > > Fair enough, however that is not a justification for keeping a potentially > incorrect schema around. We can always keep a backup of the current > database for historical purposes before the fix. > > I was not around in the pre 1.0 days, but I believe upgrades were executed > by manually running SQL scripts. I would therefore argue that differences > such as: > > - columns of VARCHAR type that are expected to be INTEGER (or some variant > of it) > - columns of smaller size, e.g. number(7) vs number(10), text vs longtext > - incorrect default values > - missing unique index on mantis_user_table.username > > are the result of missing, wrong or improperly executed upgrade steps, > which could potentially lead to bugs. > > |
From: Robert M. <rob...@gm...> - 2013-09-16 19:39:34
|
On Sun, Sep 15, 2013 at 2:12 AM, Damien Regad <dr...@ma...> wrote: > Hi > > I wanted to run an upgrade test from 1.2 to 1.3 on PostgreSQL. To have a > more realistic case than upgrading an empty database, I decided to use a > dump from our tracker, which I converted and imported. > > Running Mantis after that gave me a lot of SQL errors which made no sense in > terms of the code I had modified, so I started looking in details and > finally found out that the schema definition does not match a "standard" 1.2 > fresh install. > > I noted (excluding plugin-specific tables): > - 2 extra tables (mantis_tasks_table, mantis_upgrade_table) > - 49 differences in indexes (extra, missing, different name, different > definition, e.g. unique) > - 130 column type differences, > - 61 default values differences > - 1 column which should be "not null" but is not > > I generated an SQL script (attached) by comparing the schemas to correct the > differences, and executed it. > > As my script failed to create a missing unique index on username column, I > uncovered 2 cases of duplicate keys in mantis_user_table, (users 'updater', > 2 records, and 'dmok', 3 records). After carefully checking that these > accounts were not referenced anywhere in the database, I deleted the extra > records (keeping only the one that was created first). > > Then I carefully compared the reference schema with the updated ones, and > found no further differences in tables or indexes definitions. > > Unless someone objects, I would like to run this script on the official > tracker to align the schema to "standard". > > Note regarding the 2 extra tables (that would be dropped by my script): > - mantis_upgrade_table contains an upgrade_id (mantis version + sequence > number) and a text description of the change > - mantis_tasks_table: contains just test data created in 2001 > These are possibly leftovers from an earlier (very old) version of Mantis, I > don't know, but I don't think there is any value in keeping that. > > Let me know your thoughts > Damien I'm all in favour of making the schema identical to a 'clean' MantisBT install. I see no practical reason for which we should keep the old schema around. Robert > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. > http://pubads.g.doubleclick.net/gampad/clk?id=64545871&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > -- http://robert.muntea.nu/ |
From: Gianluca S. <gi...@gm...> - 2013-09-17 08:52:07
|
On Mon, Sep 16, 2013 at 9:39 PM, Robert Munteanu <rob...@gm...> wrote: > I'm all in favour of making the schema identical to a 'clean' MantisBT > install. I see no practical reason for which we should keep the old > schema around. +1 -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu |
From: Damien R. <dr...@ma...> - 2013-09-23 08:35:12
|
Thanks for your feedback. You've missed what is probably the most important point > - columns of VARCHAR type that are expected to be INTEGER (or some > variant of it) I take your points for the rest, and agree that in most cases the differences have little consequence, but as we have standardized on a tool to define and maintain the schema, then our own database should be aligned to that definition. As for allowing 4GB, true it's completely overkill but at the same time it does not hurt, does it ? > ^ I'm inclined to look back at this with a view to adding a database > check for mysql only to fix this on old datasets. As we can probably add > a fix for this fairly easily. So you think this should be addressed as part of install.php ? D On 2013-09-16 22:16, Paul Richards wrote: > Right, > > The number(7) vs number(10) is caused the our migration to adodb. > > Basically, historically we set INT(7) as data type, with an auto/zero > fill so the number returned from db was 000023 or similar. When we then > looked at other databases, that filling was moved into the PHP code I > believe. > > At the same time, with the move to adodb, we stopped specifying the > length field e.g. (7)/(10), hence the difference. > > In terms of mysql, the (7)/(10) represents the display width of a column > if zero fill is enabled, and does not alter the size of the data field - > it's 4 bytes in both case. Therefore this doesn't actually make any > difference, and we can just ignore > > In terms of the text vs longtext, I'm half inclined to think that our > database ( the non-12 one) probably has it correct for some fields at least: > > a) text = 75KB > b) mediumtext = 16MB > c) longtext = 4GB > > Allowing 4GB for a token for instance seems rather silly. For a bug > description, I could imagine you *could* hit the 75KB limit, but.... > > For the remaining two issues: > > - incorrect default values > ^ I'm inclined to look back at this with a view to adding a database > check for mysql only to fix this on old datasets. As we can probably add > a fix for this fairly easily. > > - missing unique index on mantis_user_table.username > ^ I'd say that's worth manually running against the database - the index > should be there as you say, and that's in the script. If I had to make a > guess, there is/was a duplicate username, therefore the index part of > the upgrade wouldn't apply, and instead of someone fixing that, they've > just skipped the index. > > Paul > > - however, I'd be inclined > to be against manually running a script. Our bug tracker is oldest > tracker we have that's been updated through all releases.. > Therefore, if > > that doesn't match, we need to investigate why for each instance > where > it is different. > > > Fair enough, however that is not a justification for keeping a > potentially incorrect schema around. We can always keep a backup of > the current database for historical purposes before the fix. > > I was not around in the pre 1.0 days, but I believe upgrades were > executed by manually running SQL scripts. I would therefore argue > that differences such as: > > - columns of VARCHAR type that are expected to be INTEGER (or some > variant of it) > - columns of smaller size, e.g. number(7) vs number(10), text vs > longtext > - incorrect default values > - missing unique index on mantis_user_table.username > > are the result of missing, wrong or improperly executed upgrade > steps, which could potentially lead to bugs. > |
From: Paul R. <pa...@ma...> - 2013-09-23 08:44:01
|
4gb: doesn't hurt - requires more ram on db server [i.e. 1-2bytes/record] - although in some cases, data is stored within the table row up to a certain size, and then stored outside the row is a pointer after that. Remember, we also agreed to move away from adodb and replace the db layer due to the problems it's given us. Hence writing a pdo replacement. So now's a good time to work out what the correct schema should be, because it may be that the 'broken' adodb schema's we've generated over the years are incorrect anyway. [I know in the case of pgsql/mssql this was definitely the case - I thought that in the case of MySQL we were fairly good and hadn't be hit by any issues - you seem to be proving otherwise]. There are already several 'tidy up schema' updates in the 2.x branch, so adding a few more doesn't feel like an issue. I'd rather do that then have issues going forwards on old data sets due to some old adodb bug. On Mon, Sep 23, 2013 at 9:30 AM, Damien Regad <dr...@ma...> wrote: > Thanks for your feedback. > > You've missed what is probably the most important point > > > - columns of VARCHAR type that are expected to be INTEGER (or some > > variant of it) > > I take your points for the rest, and agree that in most cases the > differences have little consequence, but as we have standardized on a > tool to define and maintain the schema, then our own database should be > aligned to that definition. > > As for allowing 4GB, true it's completely overkill but at the same time > it does not hurt, does it ? > > > ^ I'm inclined to look back at this with a view to adding a database > > check for mysql only to fix this on old datasets. As we can probably add > > a fix for this fairly easily. > > So you think this should be addressed as part of install.php ? > > D > > > On 2013-09-16 22:16, Paul Richards wrote: > > Right, > > > > The number(7) vs number(10) is caused the our migration to adodb. > > > > Basically, historically we set INT(7) as data type, with an auto/zero > > fill so the number returned from db was 000023 or similar. When we then > > looked at other databases, that filling was moved into the PHP code I > > believe. > > > > At the same time, with the move to adodb, we stopped specifying the > > length field e.g. (7)/(10), hence the difference. > > > > In terms of mysql, the (7)/(10) represents the display width of a column > > if zero fill is enabled, and does not alter the size of the data field - > > it's 4 bytes in both case. Therefore this doesn't actually make any > > difference, and we can just ignore > > > > In terms of the text vs longtext, I'm half inclined to think that our > > database ( the non-12 one) probably has it correct for some fields at > least: > > > > a) text = 75KB > > b) mediumtext = 16MB > > c) longtext = 4GB > > > > Allowing 4GB for a token for instance seems rather silly. For a bug > > description, I could imagine you *could* hit the 75KB limit, but.... > > > > For the remaining two issues: > > > > - incorrect default values > > ^ I'm inclined to look back at this with a view to adding a database > > check for mysql only to fix this on old datasets. As we can probably add > > a fix for this fairly easily. > > > > - missing unique index on mantis_user_table.username > > ^ I'd say that's worth manually running against the database - the index > > should be there as you say, and that's in the script. If I had to make a > > guess, there is/was a duplicate username, therefore the index part of > > the upgrade wouldn't apply, and instead of someone fixing that, they've > > just skipped the index. > > > > Paul > > > > - however, I'd be inclined > > to be against manually running a script. Our bug tracker is > oldest > > tracker we have that's been updated through all releases.. > > Therefore, if > > > > that doesn't match, we need to investigate why for each instance > > where > > it is different. > > > > > > Fair enough, however that is not a justification for keeping a > > potentially incorrect schema around. We can always keep a backup of > > the current database for historical purposes before the fix. > > > > I was not around in the pre 1.0 days, but I believe upgrades were > > executed by manually running SQL scripts. I would therefore argue > > that differences such as: > > > > - columns of VARCHAR type that are expected to be INTEGER (or some > > variant of it) > > - columns of smaller size, e.g. number(7) vs number(10), text vs > > longtext > > - incorrect default values > > - missing unique index on mantis_user_table.username > > > > are the result of missing, wrong or improperly executed upgrade > > steps, which could potentially lead to bugs. > > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Victor B. <vb...@gm...> - 2013-09-25 05:25:22
|
Thanks Damien for detecting and investigating this... Is there a way to classify the differences in the following buckets? - Bucket 1 - these are differences that only apply to our instance -- e.g. we installed an plugin and didn't install it properly or an issue that is specific to our deployment of development builds (dev builds exclude alpha builds and rc builds that we official release -- I'm referring to night builds / git builds). - Bucket 2 - these are issues like the ones Paul referred to, e.g. issues that was caused by the way we created tables over time or schema upgrades, etc. I think these issues will exist in user instances and we may need to have the 2.0 schema upgrader handle them. We could argue for clean our tracker now and then test on a backup. We can do that, but we will be testing a bug tracker that is different than what our users are running in case they had an instance that has been up for sometime and has gone through several major upgrades. Thanks, -Victor On Mon, Sep 23, 2013 at 1:43 AM, Paul Richards <pa...@ma...> wrote: > 4gb: doesn't hurt - requires more ram on db server [i.e. 1-2bytes/record] > - although in some cases, data is stored within the table row up to a > certain size, and then stored outside the row is a pointer after that. > > Remember, we also agreed to move away from adodb and replace the db layer > due to the problems it's given us. Hence writing a pdo replacement. > > So now's a good time to work out what the correct schema should be, > because it may be that the 'broken' adodb schema's we've generated over the > years are incorrect anyway. [I know in the case of pgsql/mssql this was > definitely the case - I thought that in the case of MySQL we were fairly > good and hadn't be hit by any issues - you seem to be proving otherwise]. > > There are already several 'tidy up schema' updates in the 2.x branch, so > adding a few more doesn't feel like an issue. I'd rather do that then have > issues going forwards on old data sets due to some old adodb bug. > > > On Mon, Sep 23, 2013 at 9:30 AM, Damien Regad <dr...@ma...> wrote: > >> Thanks for your feedback. >> >> You've missed what is probably the most important point >> >> > - columns of VARCHAR type that are expected to be INTEGER (or some >> > variant of it) >> >> I take your points for the rest, and agree that in most cases the >> differences have little consequence, but as we have standardized on a >> tool to define and maintain the schema, then our own database should be >> aligned to that definition. >> >> As for allowing 4GB, true it's completely overkill but at the same time >> it does not hurt, does it ? >> >> > ^ I'm inclined to look back at this with a view to adding a database >> > check for mysql only to fix this on old datasets. As we can probably >> add >> > a fix for this fairly easily. >> >> So you think this should be addressed as part of install.php ? >> >> D >> >> >> On 2013-09-16 22:16, Paul Richards wrote: >> > Right, >> > >> > The number(7) vs number(10) is caused the our migration to adodb. >> > >> > Basically, historically we set INT(7) as data type, with an auto/zero >> > fill so the number returned from db was 000023 or similar. When we then >> > looked at other databases, that filling was moved into the PHP code I >> > believe. >> > >> > At the same time, with the move to adodb, we stopped specifying the >> > length field e.g. (7)/(10), hence the difference. >> > >> > In terms of mysql, the (7)/(10) represents the display width of a column >> > if zero fill is enabled, and does not alter the size of the data field - >> > it's 4 bytes in both case. Therefore this doesn't actually make any >> > difference, and we can just ignore >> > >> > In terms of the text vs longtext, I'm half inclined to think that our >> > database ( the non-12 one) probably has it correct for some fields at >> least: >> > >> > a) text = 75KB >> > b) mediumtext = 16MB >> > c) longtext = 4GB >> > >> > Allowing 4GB for a token for instance seems rather silly. For a bug >> > description, I could imagine you *could* hit the 75KB limit, but.... >> > >> > For the remaining two issues: >> > >> > - incorrect default values >> > ^ I'm inclined to look back at this with a view to adding a database >> > check for mysql only to fix this on old datasets. As we can probably add >> > a fix for this fairly easily. >> > >> > - missing unique index on mantis_user_table.username >> > ^ I'd say that's worth manually running against the database - the index >> > should be there as you say, and that's in the script. If I had to make a >> > guess, there is/was a duplicate username, therefore the index part of >> > the upgrade wouldn't apply, and instead of someone fixing that, they've >> > just skipped the index. >> > >> > Paul >> > >> > - however, I'd be inclined >> > to be against manually running a script. Our bug tracker is >> oldest >> > tracker we have that's been updated through all releases.. >> > Therefore, if >> > >> > that doesn't match, we need to investigate why for each instance >> > where >> > it is different. >> > >> > >> > Fair enough, however that is not a justification for keeping a >> > potentially incorrect schema around. We can always keep a backup of >> > the current database for historical purposes before the fix. >> > >> > I was not around in the pre 1.0 days, but I believe upgrades were >> > executed by manually running SQL scripts. I would therefore argue >> > that differences such as: >> > >> > - columns of VARCHAR type that are expected to be INTEGER (or some >> > variant of it) >> > - columns of smaller size, e.g. number(7) vs number(10), text vs >> > longtext >> > - incorrect default values >> > - missing unique index on mantis_user_table.username >> > >> > are the result of missing, wrong or improperly executed upgrade >> > steps, which could potentially lead to bugs. >> > >> >> >> >> ------------------------------------------------------------------------------ >> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! >> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, >> SharePoint >> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack >> includes >> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk >> _______________________________________________ >> mantisbt-dev mailing list >> man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > |