Greg Stein <gstein_at_gmail.com> writes:
> On Thu, Jun 2, 2011 at 12:32, <philip_at_apache.org> wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_wc/wc-queries.sql Thu Jun 2 16:32:18 2011
>> @@ -726,6 +726,10 @@ VALUES (?1, ?2, ?3)
>> SELECT locked_levels FROM wc_lock
>> WHERE wc_id = ?1 AND local_dir_relpath = ?2
>>
>> +-- STMT_COUNT_WC_LOCK
>> +SELECT COUNT(*) FROM wc_lock
>> +WHERE wc_id = ?1
>
> You don't need the actual count. Just whether one exists. Thus, I'd
> recommend switching this over to STMT_HAS_WC_LOCK and do a simple
> select with LIMIT 1 on it. Basically: it will be much easier on SQLite
> because it doesn't have to count the number of rows. Just give you
> one.
The count is used:
/* Next check for a lock at root. */
SVN_ERR(svn_sqlite__get_statement(&stmt, wcroot->sdb, STMT_SELECT_WC_LOCK));
SVN_ERR(svn_sqlite__bindf(stmt, "is", wcroot->wc_id, ""));
SVN_ERR(svn_sqlite__step(&have_row, stmt));
if (have_row)
locked_levels = svn_sqlite__column_int64(stmt, 0);
SVN_ERR(svn_sqlite__reset(stmt));
if (have_row)
{
*locked = (locked_levels == -1 || locked_levels >= depth);
if (*locked || num_locks == 1)
^^^^^^^^^
return SVN_NO_ERROR;
}
but I guess that could be removed. In non-legacy 1.7 a single lock will
be fully recursive so that num_locks check isn't needed; it only comes
in to play when there is a single, legacy API lock on the root.
I suppose if STMT_HAS_WC_LOCK is faster than STMT_COUNT_WC_LOCK then we
would be optimising for non-legacy locks, which is probably what we
want.
--
Philip
Received on 2011-06-02 19:05:31 CEST