ok, so the estate stores now want their own migration files, but as it
happened the SQL definition were inside the Region migrations.
It seems better/cleaner to keep each 'store' separately updatable.
WARNING: any editing in the middle of the migration scripts (as opposite
to just appending to them) has the potential of messing up updates of
existing databases. As far as I can see, this one is (probably) safe,
the worst that could happen is the EstateStore migration silently fail
if the estate the tables are already there.
This was needed if we want to update to the latest MySQL
connector dll. It automatically converts CHAR(36) to
Guids, so getting them as strings no longer works.
By using DBGuid.FromDB(), we unlink from any particular
storage format of GUIDs, could even make them BINARY(16)
if we like.
Actually not all MySql units are touched, but the remaining ones don't
seem to be affected (they don't read GUIDs from DB)
CHANGES THE ASSET SERVER PROTOCOL and means you CAN NOT MIX PRIOR VERSIONS
WITH LATER ONES. It may also eat your babies, yada, yada, yada.
The usual cautions for migrations to the assets table apply.
Coding: Can not guarantee nut free.
of a region and joining it to an existing estate or creating a new estate,
as well as creating an estate owner if in standalone, and assigning estate
owners. In Grid mode, existing users must be used. MySQL ONLY!!!! so far, as
I can't develop or test for either SQLite or MSSQL.
to start estates at 100. Existing databases having autcreated estates below
100 will see a gap in estate numbering. Other database implementors need to
ensure that no estates with numbers less that 100 are autocreated, unless
they are prepared to deal with the viewer's built-in notions of
Linden Mainland
only tested for a single user so this may still fail for multiple users
this may well be all academic anyway since standalone need to persistently store home location in presence data in some way
This is the big one. master is now presence-refactor (pre 0.7). A new branch 0.6.9-post-fixes and leading tag 0.6.9 has been created. The Presence-refactor
branch remains for experimental work.
This resolves the problem where eyes and hair would turn white on standalone configurations
When a client receives body part information, for some insane reason or other it always ends up uploading this back to the server and then immediately re-requesting it.
This should have been okay since we stored that asset in cache. However, the standalone asset service connector was not checking this cache properly, so every time the client made the request for the asset it has just loaded it would get a big fat null back in the face, causing it to make clothes and hair white.
This bug did not affect grids since they use a different service connector.
