Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Arantor
3031
Features / Re: Auto_increment madness...
« on July 11th, 2012, 05:02 PM »
Quote
Looks like the operation isn't 'free' on large tables, and I don't want to go with dummy rows (concurrent queries?), so if we ever implement that, it would have to be only on 'small' tables...
Dummy rows is a sure-fire way to cause race conditions because you just cannot guarantee the order in which things hit the server.

I honestly thought this was a free operation, I didn't realise that it was done with a complete table clone, the sort of thing only usually reserved for row-changing table changes (ones that change the physical properties of a column)

Seems like it would rule such things out as we can't judge what is a 'small' table and what is a 'big' table for any given host that Wedge is deployed on.
3032
Features / Re: Auto_increment madness...
« on July 11th, 2012, 04:13 PM »
Quote from Pandos on July 11th, 2012, 12:41 PM
This will look for "empty" ID's and put it into the database. Soo you can besure to have always the right value in your databse.
That is an instant race condition waiting to happen (which is why auto-increment even exists in the first place)
3033
Features / Re: Github & stuff
« on July 11th, 2012, 04:12 PM »
Here's the thing, though: WP doesn't just make use of SVN in its own repo, it deploys an SVN repo for each plugin author, and pushing versions of plugins also works from that repo (it's the only way to publish plugins on the master site)

I don't recall them being too hot about accepting patches from outside, however their bug tracker does regularly have patches posted, and as such everything is more integrated.
Quote
Do we want other developers to join in and share their code? Yes we do.
Here's the thing: when the time comes how likely are we going to be to accept their code as-is for inclusion?
Quote
Thus, I'm spending a lot of time trying to get used to the idea that I'll have to use that annoying pseudo-social network...
Git != Github. We can happily run our own private Git server if we want to do that, which uses all the same tools as Github does, except without the insane fake-social aspect.
3035
Features / Re: Auto_increment madness...
« on July 11th, 2012, 12:57 AM »
Yes, it's mentioned in that page. Did you notice the date of said comment? It's *nine years old*. That's around the time MySQL 4.0 left beta.

Almost everyone citing this doesn't even know which table engine they're using in on (and is repeating that comment from 2003), and in almost every case the advice predates MyISAM being deprecated as being the default. There are issues in InnoDB with it 'forgetting' the auto-increment value, which is specifically why I asked about it.

I also have no idea if it'll break replication sets either, though I'd hope it wouldn't. Changing table structures is never a safe procedure. It's usually safe but it's not certainly safe even if it's a soft non-blocking operation (in most cases) like this should be.
3036
Features / Re: Auto_increment madness...
« on July 10th, 2012, 05:35 PM »
Does that hold true for InnoDB? Does it still hold true if you shut down MySQL, restart it, and then apply that alter instruction?

* Arantor is very wary of relying on such behaviour.
3037
Features / Re: Auto_increment madness...
« on July 10th, 2012, 04:52 PM »
Quote
If we could simply call ALTER TABLE {db_prefix}drafts AUTO_INCREMENT=1, where the auto_increment value would be set to the earliest 'available' id, that means it would be much slower for the table to reach its maximum size.
That's just begging for a race condition bug.

Consider this scenario:
draft 100 is deleted
select max(id_draft) from wedge_drafts -> returns 99
draft 101 is added in the meantime
table is updated for its auto-increment to 99

But now we have an entry after 99, and this sort of stuff is far more likely than you might imagine.
3038
Off-topic / Re: Styling progress bars
« on July 9th, 2012, 03:56 AM »
That all assumes you just want to restyle the progress bar element, as opposed to say, rolling your own and being done with it, but certainly it's interesting.
3039
Features / Re: Like types?
« on July 8th, 2012, 11:27 PM »
Dealing with the action is easy enough (though it's the wrong way to do it, there should be a proper disable setting, to also prevent loading it and running the query to get the like information too)

That doesn't solve removing it from the template, though...
3040
Features / Re: Like types?
« on July 8th, 2012, 07:26 PM »
Not at the moment, sadly. But one should be added.

There's also no way - programmatically or otherwise - to disable it, but again that should get added sometime.
3041
Features / Re: Like types?
« on July 8th, 2012, 03:46 PM »
That's not my favourite operating system either.

I'm all for giving people choice and I can fully envisage there being multiple reputation-type systems for Wedge but only a basic functional likes system in the core and anything else will sit next to or notionally replace it.

I feel that best represents what our users want from us.
3042
Features / Re: Very cool Thumbnail generation...
« on July 8th, 2012, 06:19 AM »
Well... technically all the Wedge JS becomes one line ;)
3043
Features / Re: Like types?
« on July 8th, 2012, 06:18 AM »
Public Display of Affection.

SMF's system for such is user-level karma (users can + or - another user's karma once per day), which as you can imagine does not work all that well, and we considered it would be much better to tie it into posts rather than to users, per se - what you see here as far as likes go (at the bottom of posts) is what Wedge has built in at this point.

I have no intention of bundling any add-ons with Wedge itself, but making it very easy to obtain such should you want. I am not going to get into the madness that is 'picking a distribution for installation'.
3044
Features / Re: Like types?
« on July 8th, 2012, 05:25 AM »
Quote
I agree. I think the whole "like" system should be a plug in. And what I described was definitely functionality that keys off a reputation system.
The base like system is already a core feature, and it will not be deprecated to plugin status any time soon. I consider it a required function in the core at this time, because I consider that *some* kind of reputation mechanic should be in the core and it is the least useless one I've seen. I'm also mindful of the fact that we do have to compete meaningfully with other platforms and that something perceived to be as basic as a 'like system' is both very desirable in the core and considered to be core functionality in other platforms.

However, I'm well aware that going much further than the base like system that is currently implemented is headed firmly into plugin territory.
Quote
You bring up a very interesting point, the purpose of the forum will heavily influence the form of any "like" systems. It would probably be best to have the hooks for the activation button and the Public Display of Like Comments, and let the specific "like" pluggin chosen do the work
Which is basically how it works. I consider that the general use of 'likes' as implemented is sufficiently generic that almost any kind of forum could use it if nothing better is available, though I will put in an option to disable it at some point. Note that in XenForo for example it doesn't not appear to be able to disable it.
Quote
I do think that the admin should pick ONE "like" systems to install, and that the interfaces are well defined, but don't assume much about the "like" functionality.
Hmm. I don't like forcing admins to make a choice like that. It's actually better from a usability point of view that a basic version is built in by default and that plugins can do what they will with it, rather than removing everything and making anyone who wants reputation have to install a plugin.

Imagine you're looking to choose a forum system: are you seriously going to choose a forum system that has absolutely zero reputation systems built in?

(Let me clarify this. Back in 2006, I started out running a forum with PunBB. The *sole* reason I moved to SMF all those years ago, and the seed for everything here today is because PunBB did not have something as 'simple' as polls built in, and already on this forum, Likes gets more use than polls.)
3045
Features / Re : Github & stuff
« on July 7th, 2012, 06:44 PM »
I believe hg might have that, I'm not so sure about exactly what it can or can't do.