[Opensim-dev] Search server DB schema

David Wendt JR. dcrkid at yahoo.com
Mon Feb 4 22:40:24 UTC 2008


Hello again, Opensim-dev

    I'm agreeing with Dalien Talbot. Authoritative parcel data should be on the region, not the grid, since it doesn't need to be shared grid-wide for the base functionality to work. However, SearchServer will have to have a copy of the parcel data that's fairly recent for it to function. Otherwise, the server would have to pull data from every region for every search request, and we don't want that. 

    I've thought about search some more and realized that, when we implement the HTTP-based search, we'll be able to arbitrarily extend the search capabilities to whatever we want. In Old Search when searching for land, you only had a few options: "Max. Price", "Min. Area", the type of land sale (Auction, Mainland Sale, or Estate Sale), and the location of the land (PG or Mature). In HTTP search we can add all kinds of search constraints. What I'm getting at, is what should we be putting into the SearchServer database schema. For old search we just need enough data to fulfill the viewer request. However if we're going to add extra constraints in HTTP search, we will need extra fields. I'm wondering if it would be prudent to just have a column for everything the sim stores.

    I know Dalien Talbot asked if I had considered non-relational searches. I myself haven't played with non-relational databases. But for now I think we should stick with a relational storage backend.

    SearchServer will actually be handling four separate types of searchable data. Parcels, Objects, Classifieds, and the Events calendar. While Justin Clark-Casey wanted to join these altogether into one table, I doubt that would help much. Sure we wouldn't have duplicate fields, but we'd have many more rows that mysql would have to go through in order to find matching ones. There's not much overhead to having each table have a few columns that are the same.

    Also another thing I just realized, how are we gonna search Users and (when we support them) Groups? I don't think we should assume that UserServer and SearchServer are accessing the same datastore. I.E. we shouldn't just have SearchServer query the users table. We could have the sim query UserServer directly. I already see AvatarPickerRequest-related searcher code in the UserServer which we could leverage directly without going thrugh SearchServer.

    But I'm getting off-topic here. I need to start working on an actual DB schema (SQL code) and propose it sometime. Also can anyone tell me what's the maximum length of a name and description field in Second Life? I'm going to assume name == varchar(63) and description == varchar(127), but it might be easier to just set everything to varchar(255) for flexibility.

    From,
        KMeist Hax.




      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080204/37f34c55/attachment-0001.html>


More information about the Opensim-dev mailing list