Вы только обновляете измененные поля или все поля?

Вы можете использовать эту функцию для доступа к параметрам URL

var getParams = function (url) {   
    var params = {};
    var parser = document.createElement('a');
    parser.href = url;
    var query = parser.search.substring(1);
    var vars = query.split('&');
    if(vars == ''){
        params = '';
        return params;
    }
    for (var i = 0; i < vars.length; i++) {
        var pair = vars[i].split('=');
        params[pair[0]] = decodeURIComponent(pair[1]);
    }
    return params;
};

и вызова его

console.log(getParams(window.location.href));
.
10
задан Juan Mellado 1 May 2012 в 13:35
поделиться

3 ответа

Я думаю, что это стоит изменить - но вероятно не стоящее выполнения выбор, прежде чем вставят.

Я только обновляю поля, которые изменились, это - часть операции моего класса DbEntity, который следует за activerecord шаблоном. Это стоит малого дополнительного, чтобы сделать это, потому что я держу текущие рекордные и исходные записи - просто копирование каждый раз, когда запись загружается.

Причинами является краткость - не действительно производительность. Также можно проверить на параллельную модификацию путем добавления, где пункт на старом значении обновленных полей и бросает соответствующую ошибку.

В методе записи/обновления:

$s1 = "";

foreach ($this->record as $key => $value)
{
    // only update fields that have been changed
    if ($value != $this->orig_record[$key])
    {
        $s1 .= $comma."`$key`='".mysql_real_escape_string($value)."'";
        $comma = ", ";
    }
}

$query = "UPDATE ".$this->table." SET $s1 where {$this->id_field}='".$this->get_keyfield()."'";
$query .= $this->extra_sql_update;
mysql_query($query);

$ar = mysql_affected_rows();
//
// the number of affected rows is actually those changed by the update operation, which will 
// either be zero, or 1. If the query affects more than one row then we have a problem.
if ($ar < 0 || $ar > 1)
{
    cbf_error("cbf_dbentity: {$this->table} :: only one row (not $ar) must be affected by an insert operation. $query",
      E_USER_ERROR);
}
else
{
    $new_id = $this->get_keyfield();

    GlobalEventBus::notify_all(new AuditLogSQL($this->table, "update", $query));

}

$this->orig_record = Array();

foreach ($this->record as $key => $value)
    $this->orig_record[$key] = $value;


//
// sanity check - ensure that what we have just written is actually there.

$this->load($new_id);

foreach ($this->orig_record as $key => $value)
    if (trim($this->record[$key]) != trim($value) 
        && (!$this->record[$key] == "0" && $value=""))
        cbf_error("cbf_dbentity: {$this->table} :: record differs during write after reload: field $key was \"$value\", after write it is now \"".
              $this->record[$key]."\"",E_USER_ERROR);

В методе загрузки

$this->orig_record = Array();
foreach ($this->record as $key => $value)
    $this->orig_record[$key] = $value;
3
ответ дан 4 December 2019 в 03:17
поделиться

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

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

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

Мы реализовали один метод здесь, посредством чего Вы добавляете метку времени обновления или столбец числа инкрементного обновления к Вашей таблице. Затем в Вашей песочнице/памяти можно отслеживать, которых полей Вы изменили (oldvalue/newvalue), и можно свободно выпустить обновление SQL для той записи для тех полей, "ОБНОВИТЬ... ГДЕ UPDATENUM=the-original-number" (или ГДЕ UPDATETS=the-original-timestamp), удостоверяясь, что Ваше обновление SQL также увеличивает UPDATENUM или UPDATETS, как соответствующие. Если затронутый записями тем обновлением, которое SQL 0, Вы знаете, что кто-то еще уже изменил ту запись в фоновом режиме, и у Вас теперь есть конфликт. Но по крайней мере Вы не перезаписывали чужие изменения, и можно затем перечитать новые данные или сделать, чтобы пользователь разрешил конфликт.

2
ответ дан 4 December 2019 в 03:17
поделиться

Самая медленная точка в Вашем приложении всегда будет Вашим доступом к базе данных, поэтому если можно ускорить это, это - хорошая идея. Это сказало, что действительно зависит, насколько большой Ваша база данных и записи, и как большой они, вероятно, вырастут до, относительно того, стоит ли это усилия программно проверить, обновили ли объекты. Если Ваша база данных является маленькой, и доступ уже довольно быстр, это не может стоить времени. Но если скорость может быть улучшена, и она приносит Вам дополнительную пользу для Вашего входа, затем пойдите для нее.

1
ответ дан 4 December 2019 в 03:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: