paintActiveLocks error on upgrade?

Squiz Matrix Installation
1

Just curious if anyone has seen the following error before?

    Raw Entry:	[30-Nov-2009 09:00:02] PHP Fatal error: Uncaught exception 'Exception' with message 'Assertion failed: [NULL] "" is not a valid asset ID' in /home/websites/mysource_matrix/core/include/assertions.inc:507
    Raw Entry:	Stack trace:
    Raw Entry:	#0 /home/websites/mysource_matrix/core/include/assertions.inc(480): trigger_exception('[NULL] "" is no...', false, true)
    Raw Entry:	#1 /home/websites/mysource_matrix/core/include/asset_manager.inc(1090): assert_valid_assetid(0)
    Raw Entry:	#2 /home/websites/mysource_matrix/core/include/system_config_edit_interface.inc(453): Asset_Manager->getAsset(0)
    Raw Entry:	#3 /home/websites/mysource_matrix/core/include/system_config_edit_interface.inc(186): System_Config_Edit_Interface->paintActiveLocks(Object(Backend_Outputter))
    Raw Entry:	#4 /home/websites/mysource_matrix/core/include/backend.inc(1444): System_Config_Edit_Interface->paint(Object(Backend))
    Raw Entry:	#5 /home/websites/mysource_matrix/core/include/backend.inc(189): Backend->_printMain()
    Raw Entry:	#6 /home/websites/mysource_matrix/core/include/mysource.inc(410): Backend->paint()
    Raw Entry:	#7 /home/websites/mysource_matrix/core/web/index.php(30): MySource-> in /home/websites/mysource_matrix/core/include/assertions.inc on line 507


It comes up when I go to the Active Locks screen. This is still on my 3.24.1 dev VM that I am testing upgrades on, but I just wanted to make sure there was not another root issues causing this.
2

[quote]
It comes up when I go to the Active Locks screen. This is still on my 3.24.1 dev VM that I am testing upgrades on, but I just wanted to make sure there was not another root issues causing this.

[/quote]





Are you using memcache?



If you are not using memcache, try checking out the database and see if there is a lock for a user '0'

3

[quote]
Are you using memcache?

[/quote]



Nope.


[quote]

If you are not using memcache, try checking out the database and see if there is a lock for a user '0'

[/quote]



I am pretty bad at queries, how would I write that?



Edit: Looks like this happens between the 3.22.5->3.24.1 upgrade…hmmm.

4 
    select * from  sq_lock where userid = 0;

I think you are safe to delete any of those rows especially if they are expired, I think these rows hang around until someone else acquires locks on the asset. When you are upgrading hopefully there is no publishing going on.
5

[quote]

    select * from  sq_lock where userid = 0;


I think you are safe to delete any of those rows especially if they are expired, I think these rows hang around until someone else acquires locks on the asset. When you are upgrading hopefully there is no publishing going on.
[/quote]

Thanks, here is what I see:

       lockid        |    source_lockid    | userid |       expires       
    ---------------------+---------------------+--------+---------------------
     asset.31.attributes | asset.31.attributes | 0      | 2007-01-11 16:40:50
     asset.31.links      | asset.31.links      | 0      | 2007-01-11 16:40:50


And, deleting these is safe? Who is user 0?
6

[quote]


And, deleting these is safe? Who is user 0?

[/quote]

Yep perfectly safe to delete. The worst case scenario for removing locks is basically that someone will not be able to save the particular page/attribute they are working on because you've removed the lock between them starting editing and pressing Commit.



User 0 doesn't exist, but sometimes Matrix uses that ID for the current user if a script hasn't correctly set the currently logged in user (the CLI scripts distributed with Matrix should all be setting the root user I think).



Basically these entries shouldn't really have ever been there, given their expiry date I'm guessing it's from an old version (unless the timestamps on your machine happen to be wrong).



One good thing when adjusting anything via SQL is to either do it in a transaction or automate some roll back sql. I'm not very good at the roll back sql generation so I'll just explain the transaction:


    
    matrix=# begin; -- start a transaction
    BEGIN
    matrix=# delete from sq_lock;
    DELETE 116
    matrix=# rollback; -- oops way too many
    ROLLBACK
    matrix=# begin; -- start a new transaction
    BEGIN
    matrix=# delete from sq_lock where userid = '0';
    DELETE 8
    matrix=# commit; -- got it right that time.
    COMMIT
7

Yep you can delete those, you can even do something like

    delete from sq_lock where expires < current_timestamp -30;


to get rid of the old expired locks.


User 0 is 'System', I'm pretty sure everyone will have those rows unless they delete them, they are the locks for some of the very first matrix assets (login screen?)


edit: David beat me. you could also backup that table if you're worried

    create table sq_lock_bak  as select * from sq_lock ;
8

Perfect! Thank you both.