[Opensim-dev] Status of presence refactor?

[diva at metaverseink.com]

Justin Clark-Casey wrote:
> Out of interest, why is this?  

Well, what I said isn't the only possible route. Here's the technical 
issue, then I'll explain the two ways to go at it. But then I have a 
question and a warning to whoever uses SQLite.

Due to SQLite connection management constraints, the authorization data 
is being stored in a separate file than the user account data file. 
Different connections ==> different files, or things won't work. 
Conversely, one file ==> one connection, but that would mean having to 
merge the data layers for user accounts and authorization in SQLite, not 
pretty. Auth being on a separate file than the "old" userprofile db, 
data can't be copied over automatically. So, two ways to go at this:

1) Run without any pre-action, reset the password, then the right auth 
data will be placed in the right file. (this is what I meant in my 
previous email, runs without pre-action)

2) Use the old userprofiles.db as the basis for both the new 
useraccounts table and the auth tables. In other words, copy 
userprofiles.db to auth.db, then run. I have a migration in auth that 
will copy the auth data over to the auth table from the old users table.

But now, the question. Why do you think that people running OpenSim over 
SQLite have multiple user accounts, like one expects from people running 
a real DB? Can you give me some rough numbers for who is doing that?

I was under the impression that SQLite is being used for quick trials 
and for single-person worlds. I would *strongly* discourage people from 
using SQLite-powered OpenSims as if this was a sustainable multi-user 
configuration. It's not. It will bomb. Mantis #4437 is a good example of 
SQLite bombing on people. Had a bug like that affected MySQL, it would 
have been fixed in no time. It affecting SQLite, the issue has been open 
for over 2 months, and the fix is not in sight. More than SQLite 
performing poorly, which it does for large DBs, the main danger here is 
the lack of support for when things go wrong.