| Commit message (Collapse) | Author | Files | Lines |
|---|
|
like they've been active for at least 2 and a half years
|
|
wrong key
|
|
Using MyISAM proves vastly faster for persisting scene objects.
For instance, a scene object that took 9 seconds to persist before now takes 1. This also improves the experience of loading large OARs.
We don't use any of the transactional features of InnoDB.
The only thing that may have an impact is that InnoDB does row locking on inserts while MyISAM does table locking.
However, field reports say there is no noticeable difference.
|
|
characters of each field -- that's the UUIDs. Thanks coyled. WARNING: Again, people who have gone through this migration and failed need to run it manually.
|
|
Revert "Changed Friends table to have 165-sized varchars on PrincipalID and FriendID. The reason for this number is the following: there is a combined key of these 2 fields; apparently MySql can't handle keys larger than 1000 bytes; when the table is created with utf8 encoding, this combined key is bigger than 1000 bytes, and the migration fails. WARNING: this is not a new migration! People who have gone through this migration and failed should update the sizes of these fields manually."
This reverts commit 3fa54a156a83e498a7d5d0949a5f848fe82fe86f.
|
|
FriendID. The reason for this number is the following: there is a combined key of these 2 fields; apparently MySql can't handle keys larger than 1000 bytes; when the table is created with utf8 encoding, this combined key is bigger than 1000 bytes, and the migration fails. WARNING: this is not a new migration! People who have gone through this migration and failed should update the sizes of these fields manually.
|
|
correctly handled. Friends list showing correct foreign names. TODO: GrantRights.
|
|
Changed the stored region names of HG regions. Increased the size of regionName in DB.
|
|
themselves. Tested. Seems to be working, main tests pass. Nothing done for IARs or HG transfers yet -- this only works for OARs for the time being.
New migration in inventory table in order to make CreatorID varchar(255).
|
|
Creator name properly shown on the viewer as first.last @authority.
New option added to save oar -profile=url. Migration on RegionStore making CreatorID be 255 chars.
Moved Handling of user UUID -> name requests to a new module UserManagement/UserManagementModule.
|
|
This will cause visual params to be persisted along with worn items. With
this, alpha and tattoo laters will be saved. Multiple layers MAY work, but
not tested because I don't use Viewer 2.
|
|
|
|
to add a LastSeen field of type "Timestamp" to Presence for MySQL
|
|
properly for the new media settings.
Signed-off-by: Melanie <melanie@t-data.com>
|
|
Signed-off-by: Melanie <melanie@t-data.com>
|
|
|
|
|
|
|
|
to add a LastSeen field of type "Timestamp" to Presence for MySQL
|
|
* Added an error message in initial estate owner creation that makes it clear what needs to happen.
|
|
|
|
|
|
* Deleted redundant migration for assets in SQLite
* Rewrote XInventory migrations in SQLite in the new style
|
|
better
|
|
|
|
(some Estate SQL left behind in the Region migration)
|
|
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.
|
|
files. Restored Presence table to its taboo-breaking form.
|
|
|
|
Replaced all NNN_StoreName.sql migration resources with a more
readable, single-file-per-store
|
|
Replaced all NNN_StoreName.sql migration resources with a more
readable, single-file-per-store
|
|
stored in regionsettings. Upon generation of a new tile image, the old one is deleted. Tested for SQLite and MySql standalone.
* Fixed small bug with map search where the local sim regions weren't found.
|
|
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.
|
|
|
|
home and position info in the presence service. WARNING: I violated a taboo by deleting 2 migration files and simplifying the original table creation for Presence. This should not cause any problems to anyone, though. Things will work with the new simplified table, as well as with the previous contrived one. If there are any problems, solving them is as easy as dropping the presence table and deleting its row in the migrations table. The presence info only exists during a user's session anyway.
BTW, the Meshing files want to be committed too -- EOFs.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from IUserAccountService, we need to define what goes in there. Change
the handler to the generic handler. Adjust migrations, add index
|
|
|
|
|
|
|
|
into the new
|
