<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=iso-8859-1>
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY id=MailContainerBody
style="PADDING-RIGHT: 10px; PADDING-LEFT: 10px; PADDING-TOP: 15px"
bgColor=#ffffff leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV dir=ltr>Hello, <BR><BR>My name is Laurent (Larry). I am a MCAD developer /
architect / instructor on behalf of a service company based in Luxembourg, and I
live in France. I'm French,
<DIV id=result_box dir=ltr>so I humbly request your indulgence for the poor
quality of my writing.<BR><BR>I am fascinated by your teamwork. So I
decided to put my nose in the OpenSim code... Thanks to it, I have learnt a lot
already about open-sourcing, third party tools I never see before (as prebuild,
nini...), and have a better idea about how mono freaks are doing.<BR><BR>Taking
a close look at the plugins database, I noticed that the persistence logic was
replicated in each, which must be difficult to maintain, and it may leads to
ennoying bugs... That's why I started to write a plugin generic database in an
attempt to find a solution to this problem.<BR><BR>It consists of an additional
OpenSim.Framework.Data.DbEngine assembly which contains the usual classes you
know that implements IAssetProvider, IGridData, IInventoryData, IUserData.
Instead of creating ADO.NET Connection, Command objects, theses classes
logic relies on an IDbEngine helper that creates thoses objects and handle
queries parameters.<BR></DIV></DIV>
<DIV dir=ltr>IDbEngine is an interface that has to be implemented by as many
classes as desired available database engine. This class helps to instantiate
ADO.NET objects the best way the specifics of the database engine allows
to.<BR><BR>As an example of code is better than too much explanations, please
find AssetData.cs here: <A
title="http://pastebin.ca/845808
CTRL + Cliquez ici pour suivre le lien"
href="http://pastebin.ca/845808">http://pastebin.ca/845808</A> and
MSSQLDbEngine here: <A
href="http://pastebin.ca/845813">http://pastebin.ca/845813</A>. <FONT face=Arial
size=2>GridData.cs, InventoryData.cs, UserData.cs have also been implemented.
Also SQLiteDbEngine.cs is ready.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><BR>However, in trying
to design this plugin, I encountered several problems. The first one stucks me a
little...<BR><BR>* The structure of the database differs from a plug to another.
<BR>For example, there is a field called assets.id in MySQL plugin, although it
is called assets.uuid in SQLite. The same way, some varchar field size are fixed
to 255 in all SQLite tables that are generated from DataSet. What about to keep
a database structure common to all plug-ins ? This would be better to keep this
new approach simple.<BR><BR>* For the moment, there is two different strategies
of access to the data: one with DataSets implemented, the other with SQL
queries. I think it's an opportunity to experiment other approaches, knowing
that the datasets eats a lot of memory when they are well filled, and chews up
performance when commit is done.<BR>Maybe we could implement stored procedures ?
The proposed approach will make possible to implement a variety of strategies,
which could be activated in turn in order to choose the most effective for a
given database engine. <BR><BR>That is, if you like the idea, I would love to
hear feedback, comments and suggestions before to continue to work on
it.<BR><BR>Sincerely, <BR>Laurent.</DIV></BODY></HTML>