Wedge

Sorry, I meant *captured* in the match. ((?:topic=)\d+) would only match the number in a backref.

Oh, yeah, nice optimisation there on the URL prompt, I missed that in passing.


As for Subs.php... I figured there had to be a reason it was there as a positive assertion so left it until I had a reason to remove it, really.

It's no less straightforward than the prompt immediately before it, IMO, but I *am* a geek which means what sounds normal to me probably isn't, heh. I'll get my better half to look at it tonight.

It isn't actually mandatory, by design, so if people hit cancel on that prompt it gives them a url bbcode with the URL itself as the linktext.

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)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)

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.

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

Part of me would like to keep it, but there's no reason it should stay unless we're seriously planning on providing the ability to deal with it later, which I doubt.

Most of the hacks for PGSQL are because SMF uses this banal system of comma-separated values in a string column. It may have made sense long ago but in the current day and age, it's not viable. Don't even get me started on trying to hack in MSSQL support, I actually gave that up as a lost cause in the current environment. (Seriously, how stupid is it not to support LIMIT x, y as a clause? You can have the TOP x rows, but can't page through like that.)

I'd kind of like to keep the code in there in case we ever want to support something alongside MySQL (i.e. community support), but really, the way it's all engineered generally, the entire query system would need rewriting to support proper query building.

In which case... you know where the delete button is, hehe :D


Hmm, maybe it is the patch executable then? Hmm, I don't know.

Anyway.

I got brave and just did this.


Revision: 48
Author: arantor
Date: 23:47:06, 05 September 2010
Message:
! Added PMs being saved in sent items by default for new accounts (install_2-0_mysql.sql)
----
Modified : /trunk/other/install_2-0_mysql.sql