On 1/20/19 7:50 PM, Paulo Nuin wrote:
> Hi
>
> I did change one of the serial numbers, from profile DB, and tested with our test user and actually saw the lists being upgraded. But the user is still complaining his lists are empty. Anything else I could do?
The intermine folks might have a better description of the list upgrade
process, but my understanding of it is that the process is designed for
case when a new mine is built. The step of making a new mine database
generates a new random number for the serialNumber in the database.
When the web app starts up, the serial numbers in the mine and
userprofile databases are compared. If they are different, then the web
app marks the lists as NOT_CURRENT and lists are upgraded on demand:
public lists are upgraded right away and private lists upgraded as the
users log in. You circumvented the process by manually setting the
status to NOT_CURRENT. I honestly don't know what happens to the list
upgrade processing when this happens.
The thing to check is the osbid (objectstore bag id) in the userprofile
database. Then look for values in the osbag_int table in the mine
database with this value of the bag id. That should be your saved list.
>
> Also, what would be the preferred way to change serial numbers?
In normal operation, you should not have to. A new mine will have a
different value. If the cases I really needed to, I just appended a
digit to the serial number with a manual SQL update.
Joe
>
> Thanks
>
> Paulo
>
>
>
>> On Jan 17, 2019, at 12:35 PM, Paulo Nuin <
[hidden email]> wrote:
>>
>> Hi Joe
>>
>> Thanks a lot. Looking at both, I see the same value
>>
>> serialNumber | 7724142468272166890
>>
>> key | serialNumber
>> value | 7724142468272166890
>> blob_value |
>>
>> I will change one and test.
>>
>> Thanks again
>>
>> Paulo
>>
>>
>>
>>
>>
>>
>>> On Jan 17, 2019, at 9:29 AM, Joe Carlson <
[hidden email]> wrote:
>>>
>>> Hello Paulo,
>>>
>>> Look in the intermine_metadata table. Before you deploy the webapp, check that the values for the key 'serialNumber' are different in the mine and the userprofile db's. It's just a random string that is generated when the dbs are built.
>>>
>>> If these have different values, then global lists are recalculated when the web app starts and private lists are recalculated when a user logs in. The status setting is not enough to trigger regenerating the lists. You'll need to update the metadata table to make one different.
>>>
>>> Joe
>>>
>>> On 1/17/19 5:46 AM, Paulo Nuin wrote:
>>>> Hi
>>>>
>>>> We have a user (logging with Google accounts) that is having trouble with empty lists after out newest release. In the past, modifying the lists to NOT_CURRENT would trigger the update, but this time the trick is not working. Any other ideas on how can we solve the problem? We have a test user that seems fine, lists contain items after the update and they work fine too.
>>>>
>>>> Our production server is dedicated, and we build on another box, dump and load and just re-release the web app when there’s an updated.
>>>>
>>>> Any help appreciated
>>>>
>>>> Thanks
>>>>
>>>> Paulo
>>>> _______________________________________________
>>>> dev mailing list
>>>>
[hidden email]
>>>>
https://lists.intermine.org/mailman/listinfo/dev> _______________________________________________
> dev mailing list
>
[hidden email]
>
https://lists.intermine.org/mailman/listinfo/dev_______________________________________________
dev mailing list
[hidden email]
https://lists.intermine.org/mailman/listinfo/dev
Locked
