| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
This was causing issues when using specified
paths to database files by using a hard-coded
name.
|
| |
|
|
| |
that it can be overwritten in subclasses. That way extensions can decide in which assembly migration resources should be looked up. This is a refactor similar to commit 9923a2ff1002d722ccebea8bf4d71718ed4e2a03 for MySQL -- no functional changes.
|
| |
|
|
| |
this would have caused dupe links bugs when using the sqlite adaptor
|
| |
|
|
| |
security to friendship identifiers so that they can safely be deleted across worlds. Had to change Get(string) to use LIKE because the secret in the identifier is not always known -- affects only HG visitors. BOTTOM LINE SO FAR: HG friendships established and deleted safely across grids, local rights working but not (yet?) being transmitted back.
|
| |
|
|
| |
FriendsData[] GetFriends(string principalID) to IFriendsData and FriendInfo[] GetFriends(string PrincipalID) to IFriendsService. Refactored some more in the FriendsModule. Made client get notification of local friends permissions upon HGLogin. HG Friends object permissions work.
|
| |
|
|
|
|
|
| |
If these links are not deleted, then they will build up in the player's inventory until they can no longer log in.
Accidental deletion of links due to bugs or other causes is potentially inconvenient but on a par with items being
accidentally moved. When a link is deleted, the target of the link is never touched.
This is a general solution that accounts for the use of links anywhere in the user's inventory.
|
| |
|
|
|
|
| |
Revert "Allow item links to be deleted even when other deletes and purges are disabled."
This reverts commit 491279f99afc65860d44765ee7829c7dd5e4e38e.
|
| |
|
|
|
|
|
| |
If these links are not deleted, then they will build up in the player's inventory until they can no longer log in.
Accidental deletion of links due to bugs or other causes is potentially inconvenient but on a par with items being
accidentally moved. When a link is deleted, the target of the link is never touched.
This is a general solution that accounts for the use of links anywhere in the user's inventory.
|
| | |
|
| |
|
|
|
|
|
|
| |
changes to all the estates that the user owns).
This applies to adding/removing estate users, groups, managers and bans.
This is the application of the AllEstates_0.5.patch from http://opensimulator.org/mantis/view.php?id=5420
Thanks very much, Snoopy!
|
| |
|
|
| |
region part of an existing estate, then list the existing region names.
|
| |
|
|
|
|
|
|
| |
from the data adaptor's Rows list in addition to calling Delete.
This matches the behaviour for other deletions and stops this operation failing on Windows .NET (though mono is fine with the duplication).
Probably a holdover from copying code from the older legacy adaptor.
Resolves http://opensimulator.org/mantis/view.php?id=5361
|
| |
|
|
| |
goetz for the initial patch in Mantis #5230.
|
| |
|
|
|
|
| |
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).
|
| |
|
|
| |
SOP.CreatorID. Untested, but should work.
|
| |
|
|
| |
from a region and allow normal day cycles to be reestablished
|
| |
|
|
|
|
|
| |
* Hopefully this will enable mac people to use SQLite again
* Someone cooler then me will need to figure out how to define CSharpSqlite with Mono so the conditional will pick up.
* There's also an error that occurs when you first load OpenSimulator under CSharpSQLite that goes away after.
* The databases are not byte for byte compatible. Mono.Data.Sqlite is able to read CSharpSqlite made databases but not the reverse way.
|
| |
|
|
|
|
|
|
|
|
| |
* Use a conditional define to determine whether we're using CSharpSqlite or Mono.Data.Sqlite
#if CSharpSqlite
using Community.CsharpSqlite.Sqlite;
#else
using Mono.Data.Sqlite;
#endif
* Hopefully, this will restore sqlite functionality on a Mac. In visual studio, you can edit the OpenSim.Data.SQLite project, go to the Build tab and enter CSharpSqlite in the box. I'm not sure how to define CSharpSqlite in Mono, someone better at it then me will have to take the job of figuring out the best way to define it in Mono.
|
| |
|
|
| |
MapAndArray collection
|
| |\ |
|
| | | |
|
| |/
|
|
|
| |
* Removed StorageManager
* CONFIG CHANGE: There are no more database settings in OpenSim.ini. Check the config-include configuration files for region store and estate store database settings
|
| | |
|
| | |
|
| |
|
|
| |
on IDwellModule
|
| |
|
|
|
|
| |
and 020 into RegionStore.migrations
This shows that panda is still not running the sqlite database tests since this change fixes the test failure in that area when "nant test" is executed locally
|
| | |
|
| |
|
|
|
|
| |
properly for the new media settings.
Signed-off-by: Melanie <melanie@t-data.com>
|
| |
|
|
| |
scene object
|
| |
|
|
| |
conditions in linking and unlinking
|
| | |
|
| |
|
|
|
| |
using an OSD serialization rather than auto forces serialization code to be placed in OpenSim.Framework
this makes the media texture raw data staging post in PrimitiveBaseShape redundant, now we just directly call the code in PrimitiveBaseShape.MediaList itself
|
| |
|
|
|
|
|
|
|
|
| |
and save events.
This is better modularity. It also allows MoapModule to be replaced with some other media module that may behave completely differently in the future.
Remaining non-modularity:
PrimitiveBaseShape needs explicit Media and MediaRaw fields. MediaRaw is required in order to shuttle the pre-serialization data back and forth from the database layer.
The database also needs to know about MediaRaw though not about Media.
IMO, it would be extremely nice to remove these hard codings but this is a bridge too far at the present time.
|
| |
|
|
|
|
| |
THIS WILL BREAK EXISTING MEDIA TEXTURE PERSISTENCE. Please delete your existing sqlite databases if you are experimenting with this branch.
This wrapper will make it easier to maintain compatibility if the media texture data evolves.
This will also make it easier to store non-sl media texture data.
|
| |
|
|
| |
this should enable persistence now
|
| | |
|
| | |
|
| |
|
|
| |
This is currently persisting media as an OSDArray serialized to LLSD XML.
|
| | |
|
| | |
|
| |
|
|
|
| |
* Deleted redundant migration for assets in SQLite
* Rewrote XInventory migrations in SQLite in the new style
|
| |
|
|
|
|
| |
estate migrations, change Sandbox to sandbox in sqlite region migrations
re-enabling the sqlite data tests revealed these errors!
|
| |
|
|
|
| |
this appears to be okay even though we reuse it between runs without deleting it first.
size of the database appears not to be changing though that could be deceptive
|
| |
|
|
| |
This addresses mantis http://opensimulator.org/mantis/view.php?id=4739
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
was less efficient.
|
| | |
|
| | |
|
