typechecker | Ламерский вопрос

в начале существования журнала все номера маленькие, а потом растут. но не подряд. так что не сходится.

Зачем гадать? Щас в исходный код посмотрю.

(хлопает в ладоши, визжит и нетерпеливо прыгает вокруг)

Получается так: число складывается из максимального нумера записи этого юзера, умноженного на 256 и int(rand(256)).

но ведь при таком раскладе можно получить дублирующиеся номера?

А как? (Это не значит, что нельзя. Это значит, что навскидку я не вижу, как.)
Каждый следующий номер заведомо больше любого существующего в 256 раз. А добавим мы 0 или что-то другое -- ерунда, т.к. отрицательные числа в int(rand(256)) не получаются.

в 256 раз??? это слишком! : ))
кажется, он больше номера предыдущего на число от 1 до 512...
rand(256) - это ведь от 0 до 255?

http://www.livejournal.com/doc/server/ljp.csp.faq.html#ljp.csp.faq.urlitemid

For protocol methods that return an itemid, there is also another variable returned called anum. To calculate the public URL itemid, use the following formula: (itemid * 256) + anum.

Если посмотреть в исходники, то увидите, что itemid = max(всех itemid для этого пользователя).

А слишком, или не слишком -- это вопрос не ко мне, а совсем даже к разработчикам.

В сорца ЖЖ всё довольно запутано, однако единственно правильный ответ получился такой:
* itemid -- это порядковый номер последней записи этого пользователя (просто его довольно черезжопно вычисляют)
* anum = int(rand(256))

Тогда всё сходится.

itemid - это порядковый номер поста в журнале, а не URL itemid. А формула - как раз расчет URL itemid.
Соответственно, если бы не было прибавления int(256), то номер следующего по порядку поста был бы больше предыдущего ровно на 256.
То есть (n-1)*256+1*256=n*256
Если бы вот эти многозначные URL номера умножались, то тогда каждый последующий номер был бы по крайней мере на два порядка больше предыдущего, на две цифры длиннее.

В наших мнениях по поводу itemid разница ровно на 1. Приведите, пожалуйста, фрагмент кода ЖЖ, из которого Вы получили Ваше знание.

Мое мнение основано на вашей цитате из кода + анализ реально существующих номеров.
В наших мнениях по поводу itemid разница ровно на 1.
Я не поняла, что вы имеете в виду.
Мы расходимся ровно в одном пункте?
Ну да, судя по этой цитате из вас:
Каждый следующий номер заведомо больше любого существующего в 256 раз.
вы считаете, что под itemid имеется в виду URL itemid прошлого поста. Почему вы так решили - не знаю. Мне же представляется, что это простой порядковый номер поста в журнале, вычисляющийся не черезжопно, а простым прибавлением 1 к прошлому порядковому номеру.
Постараюсь вам доказать вашу неправоту.
С одной стороны, повторюсь, если бы было так, как вы написали, то каждый следующий URL itemid был бы по крайней мере на две цифры длинее предыдущего.
С другой - можно просто обратиться к реально существующим номерам. Вот номера ваших последнего и предпоследнего постов: 72389 и 72189. Вы хотите сказать, что первое больше второго в 256 раз? : )

А насчет разницы между n и n-1 постом, получается все-таки от 1 до 511: если к n-1 посту с помощью операции int(rand(256)) прибавился 0, а к n-ному - 255, то разница их номеров будет:
{n*256+255} - {(n-1)*256+0}=256+255=511.
Или противоположный крайний случай:
{n*256+0} - {(n-1)*256+255}=256(n-n+1) - 255=1.

Машка, извини, что я тебе заспамила тут : )
Кстати, по этим расчетам получается, что повторяющихся номеров в одном журнале быть не может, т.к. целая часть от деления URL itemid на 256 - это собственно и есть порядковый номер записи в журнале.

Давайте так, Вы прочтёте внимательно, то, что я написал , а потом будете основывать своё мнение на моих словах.

вы считаете, что под itemid имеется в виду URL itemid прошлого поста.
Ссылку на то место указанного поста, где я это сказал.

Мне же представляется, что это простой порядковый номер поста в журнале, вычисляющийся не черезжопно, а простым прибавлением 1 к прошлому порядковому номеру.
Найдите 10 отчилий в том, что декларируете Вы, и в том, что написал я:
itemid -- это порядковый номер последней записи этого пользователя
Поскольку последней в рассматриваемый нами момент является только-что-добавленная запись, лично я разницы не вижу.

Черезжопность -- это характеристика не арифметического действия, а вот этого кода (попробуйте убедить меня в обратном):

    my $newmax;
    my $uid = $u->{'userid'}+0;
    return undef unless $uid;
    my $memkey = [$uid, "auc:$uid:$dom"];

    my $memmax = int(LJ::MemCache::get($memkey) || 0);

    my $rs = $dbh->do("UPDATE usercounter SET max=LAST_INSERT_ID(GREATEST(max,$memmax)+1) ".
                      "WHERE journalid=? AND area=?", undef, $uid, $dom);
    if ($rs > 0) {
        $newmax = $dbh->selectrow_array("SELECT LAST_INSERT_ID()");
        LJ::MemCache::set($memkey, $newmax);
        return $newmax;
    }

    if ($recurse) {
        # We shouldn't ever get here if all is right with the world.
        return undef;
    }

    my $qry_map = {
        # for entries:
        'log'         => "SELECT MAX(jitemid) FROM log2     WHERE journalid=?",
        'logtext'     => "SELECT MAX(jitemid) FROM logtext2 WHERE journalid=?",
        'talk_nodeid' => "SELECT MAX(nodeid)  FROM talk2    WHERE nodetype='L' AND journalid=?",
        # for comments:
        'talk'     => "SELECT MAX(jtalkid) FROM talk2     WHERE journalid=?",
        'talktext' => "SELECT MAX(jtalkid) FROM talktext2 WHERE journalid=?",
    };

    my $consider = sub {
        my @tables = @_;
        foreach my $t (@tables) {
            my $res = $u->selectrow_array($qry_map->{$t}, undef, $uid);
            $newmax = $res if $res > $newmax;
        }
    };

    # Make sure the counter table is populated for this uid/dom.
    if ($dom eq "L") {
        $consider->("log", "logtext", "talk_nodeid");
    } elsif ($dom eq "T") {
        $consider->("talk", "talktext");
    } elsif ($dom eq "M") {
        $newmax = $u->selectrow_array("SELECT MAX(modid) FROM modlog WHERE journalid=?",
                                      undef, $uid);
    } elsif ($dom eq "S") {
        $newmax = $u->selectrow_array("SELECT MAX(sessid) FROM sessions WHERE userid=?",
                                      undef, $uid);
    } elsif ($dom eq "R") {
        $newmax = $u->selectrow_array("SELECT MAX(memid) FROM memorable2 WHERE userid=?",
                                      undef, $uid);
    } elsif ($dom eq "K") {
        $newmax = $u->selectrow_array("SELECT MAX(kwid) FROM userkeywords WHERE userid=?",
                                      undef, $uid);
    } elsif ($dom eq "P") {
        my $userblobmax = $u->selectrow_array("SELECT MAX(blobid) FROM userblob WHERE journalid=? AND domain=?",
                                              undef, $uid, LJ::get_blob_domainid("phonepost"));
        my $ppemax = $u->selectrow_array("SELECT MAX(blobid) FROM phonepostentry WHERE userid=?",
                                         undef, $uid);
        $newmax = ($ppemax > $userblobmax) ? $ppemax : $userblobmax;
    } elsif ($dom eq "C") {
        my $commentmax = $u->selectrow_array("SELECT MAX(pendid) FROM pendcomments WHERE jid=?",
                                             undef, $uid);
    } else {
        die "No user counter initializer defined for area '$dom'.\n";
    }
    $newmax += 0;
    $dbh->do("INSERT IGNORE INTO usercounter (journalid, area, max) VALUES (?,?,?)",
             undef, $uid, $dom, $newmax) or return undef;

    # The 2nd invocation of the alloc_user_counter sub should do the
    # intended incrementing.
    return LJ::alloc_user_counter($u, $dom, 1);
}

Простите, мне не очень нравится ваш высокомерный тон.
Если вы программист, это еще не дает вам право ёрничать, ок?
Здесь вы сказали:Каждый следующий номер заведомо больше любого существующего в 256 раз.
Это утверждение неверно. Я попыталась вычислить логически, из чего вы могли сделать такой вывод. Вот и все.

Как я вижу, мы все-таки понимаем формулу одинаково.
Следите, пожалуйста, за формулировками.

Спасибо за дискуссию, я больше отвечать не буду.

Вот там я был не прав и исправился в том самом комментарии, на который Вы отвечали.

хм... а знаете, почему я решила, что вы упорствуете в своем заблуждении?? : )
Из-за фразы:
А слишком, или не слишком -- это вопрос не ко мне, а совсем даже к разработчикам.
Она... неприятно намекает на мою тупость.
А фраза Тогда всё сходится. не показалась мне признанием моей правоты.

Все, кончаю занудствовать, будем дружить : )))

А фраза Тогда всё сходится. не показалась мне признанием моей правоты.
Значит я недостаточно ясно выразился. Иногда такое случается.

Ох, я уже испугалась, что мне тут придется кости и черепа выносить. Вы уж дружите, пожалуйста, а я послушаю, мне полезно.

о, если Вы умеет туда смотреть, то, может, Вы можете найти ответ на этот вопрос?

На этот вопрос я быстро ответить не смогу. Наверное, лучше спросить группу саппорта.

Ламерский вопрос

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

Я более ощутимо заспамлю

Re: Я более ощутимо заспамлю

no subject

Все-таки отвечу : )))

Будем :)

Re: Будем :)

no subject

no subject