New revs

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #45, on September 6th, 2010, 03:30 PM »
*nods*

* Arantor hands Nao the axe to finish chopping the multi DB code out.

Point of interest: vBulletin only supports MySQL, IPB supports MySQL with MSSQL as a paid plugin (though knowing how that handles queries, it's not impossible to make it support other DBs without too much work)

Yeah, FIND_IN_SET is ridiculous, and doubly so since in PGSQL's case it doesn't exist at all, and has to be shoe-horned in as a user function (at a performance penalty, too), which returns T or F (or t or f sometimes), so you end up having to rewrite every instance of FIND_IN_SET in queries. I mean, seriously... who does it like that?
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

MultiformeIngegno

  • Posts: 1,337
Re: New revs
« Reply #46, on September 6th, 2010, 03:44 PM »Last edited on September 6th, 2010, 04:01 PM by MultiformeIngegno
What about MySQL destiny with Oracle..? Honestly I know nothing of what's happening with it, I only read scrolled ( :P ) some articles.. can it rely on a stable development?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #47, on September 6th, 2010, 03:58 PM »
I think it can. Oracle has jettisoned the areas it's not interested in (OpenSolaris for one), and MySQL is a money maker for it, especially as it can sell very expensive training, then upgrades to Oracle gear later on (with support contracts)

I don't think there's anything to fear for MySQL at the current time, and I suspect it's got life for years yet.[1]
 1. 
* Arantor waits for this to come back to haunt him haha

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: New revs
« Reply #48, on September 6th, 2010, 04:27 PM »
Quote from Arantor on September 6th, 2010, 03:30 PM
*nods*

* Arantor hands Nao the axe to finish chopping the multi DB code out.
rev 53
- Removed more of the multi-database code. (install.php, Settings.php, Settings_bak.php, create_backup.php, repair.php, repair_settings.php, restore_backup.php, smf_api.php, upgrade.php)
! Typo in repair.php, 'smc_compat_dtabase' (this should also be backported to SMF2.) (repair.php)
! Re-introducing SMF rev 9976's fix of the backup system when some tables have fields using reserved names. (DbExtra-mysql.php)

I'm not completely finished but nearly so... I should change $databases['mysql'] to just $database, but I'm a bit tired of constantly proof-reading my own code.
Quote
Point of interest: vBulletin only supports MySQL,
'course.
"We only do evil, but we're good at it." :eheheh:
Quote
Yeah, FIND_IN_SET is ridiculous, and doubly so since in PGSQL's case it doesn't exist at all, and has to be shoe-horned in as a user function (at a performance penalty, too), which returns T or F (or t or f sometimes), so you end up having to rewrite every instance of FIND_IN_SET in queries. I mean, seriously... who does it like that?
I actually like FIND_IN_SET... :lol:
But keeping it in place when trying to support other database systems would be silly, indeed.
Re: New revs
« Reply #49, on September 6th, 2010, 04:28 PM »
Quote from Arantor on September 6th, 2010, 03:58 PM
I think it can. Oracle has jettisoned the areas it's not interested in (OpenSolaris for one), and MySQL is a money maker for it, especially as it can sell very expensive training, then upgrades to Oracle gear later on (with support contracts)
I wouldn't add support for Oracle DB... My girlfriend could, though! (Well, she'd be my living documentation on their custom stuff, at least.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #50, on September 6th, 2010, 04:30 PM »
Just to clarify: FIND_IN_SET has its place, like everything else. But to use it to hunt through what is really relational data (user belongs-to group, board belongs-to group), which results in a table scan vs using indexes really is ridiculous.


When you're done with that, I'll begin on replacing $scripturl with a constant (along with the other similar globals that shouldn't really be global variables but constants)


Re Oracle: If we make the move to everything being properly relational anyway, it becomes so much easier to build for... but I don't like building for something I can't test, hahah.

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: New revs
« Reply #51, on September 6th, 2010, 04:36 PM »
Quote from Arantor on September 6th, 2010, 04:30 PM
Just to clarify: FIND_IN_SET has its place, like everything else. But to use it to hunt through what is really relational data (user belongs-to group, board belongs-to group), which results in a table scan vs using indexes really is ridiculous.
Are you sure it's inefficient? I remember reading about performance issues and the conclusion was that it was just as fast as an extra table... Couldn't say, myself. Haven't been looking into {query_see_board} and stuff for a long time.
Quote
When you're done with that, I'll begin on replacing $scripturl with a constant (along with the other similar globals that shouldn't really be global variables but constants)
Hmm... You means replacing $scripturl with SCRIPTURL?
I noticed your use of constants inside SD...
May I give you my honest opinion?
It looks kinda ugly........... :unsure:
Actually takes me back to the days of SMF1, with $ID_MEMBER, $ID_BOARD and such.
Quote
Re Oracle: If we make the move to everything being properly relational anyway, it becomes so much easier to build for... but I don't like building for something I can't test, hahah.
Same here!

+1 for going relational, though. We already have plenty of tables... Why not add a few dozen more, people won't notice :P

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #52, on September 6th, 2010, 04:42 PM »
Quote
Are you sure it's inefficient? I remember reading about performance issues and the conclusion was that it was just as fast as an extra table... Couldn't say, myself. Haven't been looking into {query_see_board} and stuff for a long time.
I don't see how it can be even close as efficient. If you're using a relational table, you have the benefit of indexes. If you're using FIND_IN_SET, you're forced to traverse the table row by row, since you can't use an index on it, and parse the row.


In the case of SMF 1 and $ID_MEMBER and so on, I know why they did that, and in practice it's... interesting. Not only describing the column by name, you're implicitly implying it forms part of a primary and/or foreign key without any other characters. That was ugly.

I'm not on the fence about it being a constant, because really, it's defined once, and used throughout the code, which means so many passes back and forth through scope that it's unreal. In terms of formatting, what about actually making it 'scripturl'? Nothing says a constant has to be upper case, but it makes it easier to see if it is.

I also believe it should be faster too.

In SD's case, it was pure readability I was going for. No way was I going to remember in every case that status 3 was resolved or that 6 was deleted, but I knew I'd follow it better with TICKET_STATUS_CLOSED or TICKET_STATUS_DELETED. I found it was only ugly initially because I wasn't used to seeing it.
Re: New revs
« Reply #53, on September 6th, 2010, 07:53 PM »
Revision: 54
Author: arantor
Date: 18:21:42, 06 September 2010
Message:
! Fixed bug in unified editor class where BBC was loaded without the post language file first, in PMs. (Class-Editor.php)
----
Modified : /trunk/Sources/Class-Editor.php

Posted: September 6th, 2010, 07:22 PM

Revision: 55
Author: arantor
Date: 18:27:53, 06 September 2010
Message:
! Quote now references the individual message only. Not 100% sure this is the fastest way to evaluate the regexp though. (Post.php, Subs.php)
----
Modified : /trunk/Sources/Post.php
Modified : /trunk/Sources/Subs.php

Posted: September 6th, 2010, 07:28 PM

Revision: 56
Author: arantor
Date: 18:53:32, 06 September 2010
Message:
! Make the quick search box be hidden if the user doesn't have permission. (index.template.php)
----
Modified : /trunk/Themes/default/index.template.php

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: New revs
« Reply #54, on September 6th, 2010, 09:22 PM »
Don't remember having ever touched the code you modified to add msg=... Are you sure it was needed? :)

rev 57
! Extra tabs/spaces, and typo fixes in comments, like its/it's and lets/let's. (Many files)
Posted: September 6th, 2010, 09:15 PM

Pete, I've re-read the install and upgrade scripts, and I really hope I got them done without breaking anything. In terms of logic, it should be okay. Just don't yell at me if you try running one of the scripts and it crashes :) I just wanted to be done with it...

rev 58
- Hopefully, removed all of the remaining multi-database code. (install.php, smfinfo.php, upgrade.php, DbPackages-mysql.php, DbSearch-mysql.php, Search.php, SearchAPI-Custom.php, SearchAPI-Fulltext.php)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #55, on September 6th, 2010, 10:47 PM »
Quote
Don't remember having ever touched the code you modified to add msg=... Are you sure it was needed?
Unless you did something funky, I found I needed it since link= doesn't accept msg on its own (it requires either (board+)topic or threadid, optionally followed by the msg number for the # fragment, or action=profile with user id for PMs)
Quote
Pete, I've re-read the install and upgrade scripts, and I really hope I got them done without breaking anything. In terms of logic, it should be okay. Just don't yell at me if you try running one of the scripts and it crashes  I just wanted to be done with it...
Well, every time I do something half way big, I push it through a fresh install, so I'll be able to test. I'm not so worried about the upgrade script right now personally (since I'm not planning to test it anytime soon :P)

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: New revs
« Reply #56, on September 6th, 2010, 10:52 PM »
Quote from Arantor on September 6th, 2010, 10:47 PM
Unless you did something funky, I found I needed it since link= doesn't accept msg on its own (it requires either (board+)topic or threadid, optionally followed by the msg number for the # fragment, or action=profile with user id for PMs)
Yeah, that was totally needed and what I'd done in the first place. (See ticket #31)
Quote
Well, every time I do something half way big, I push it through a fresh install, so I'll be able to test. I'm not so worried about the upgrade script right now personally (since I'm not planning to test it anytime soon :P)
Unfortunately, the only way to properly test a forum install is to use it... ::)
(In the end, it's my goal to convert wedgeo to a vanilla Wedge, of course.)

PS: 1000+ posts on wedgeo :)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #57, on September 7th, 2010, 12:01 AM »
Well, the installer doesn't appear to be broken...


Revision: 59
Author: arantor
Date: 22:59:27, 06 September 2010
Message:
+ Selecting IMG or URL buttons in non WYSIWYG mode prompts for IMG and URL (and also linktext for url bbc)
----
Modified : /trunk/Sources/Class-Editor.php
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/scripts/editor.js


This is essentially the same as http://arantormods.com/index.php?action=media;sa=item;in=3 except it also handles it for img too. In other news, I rediscovered that IE has a custom prompt that's used in WYSIWYG mode, I may have to remove that in the interests of cross-browser experience being the same.

Nao

  • Dadman with a boy
  • Posts: 16,063
Re: New revs
« Reply #58, on September 7th, 2010, 07:25 AM »
Great news for everything :)
(Install script or upgrade script?)
Re: New revs
« Reply #59, on September 7th, 2010, 08:00 AM »
"Please enter what text the link should say." -> Is this straightforward, or could people be confused with this? I would have said (with my limited English) something like, "You may enter a caption (description?) for the link if you'd like." It doesn't seem mandatory.