[Opensim-dev] Solution attempt about code duplication in database plugins

[Laurent B.]

Hello Sean,
 
Thank you very much for you feedback.
 
> Have you attempted this with the Prims tables yet? One of the reasons
> of the current approach is that once you get 30 columns in a table you
> end up having column definition duplication a lot with the approach you
> took, which is equally bad in terms of getting code duplication. The
> original sqlite approach was attempting to solve that, but caused other
> duplication issues in the process.
 
Yes I tried. I kept the DataAdapters approach to get it done quicker.
I have been trying MSSQL, SQlite, and (believe it or not) Jet Engine,
for MS Access.
 
It was my first try, and I had unfortunately (or not) lost the code.
The Command objects were created using a class that inherits from IDbEngine,
then attached them to DataAdapters.
 
I am planning to try to implement the prim datastore using pure SQL
queries, the same way as Asset is currently implemented.
I would like to compare performances against the current DataAdapters 
approach. I assume running a 15000 prims sim with SQLite using the
current Datastore implementation is a memory/perfs hog.
 
I agree with you according to columns definition code replication. I am
pretty sure this could be solved by using a good object design.
 
> There are enough differences in SQL engine implementations where field
> types may need to vary between implementations (though field names
> should not).
 
I agree. Despite of I am not confortable enough with SQlite and MySQL to add
more, I hope I could help people around to deal with MSSQL.
 
> The ADO.NET approach was my idea early on to avoid duplication in the
> code base. I consider it a failed experiment, as it didn't give nearly
> the amount of benefit as I was expecting, and it definitely through in a
> bunch of overhead that wasn't entirely anticipated.
 
I am sorry about this :(
I am sure you know already about it, but ADO.NET "philosophy" is not 
restricted to DataSet and DataAdapters.
It relies on a robust objet model that contains common database objects, 
interfaces, and factory patterns that is supposed to help dealing 
with different data engines : this is the way I am trying.
I remember having developed half a dozen of data access layers dedicated
to run with several data engines, using a similar approach.
Of course, they did not include tables creation nor not-CLS compliant 
types mapping. That's why the use case here is very challenging.
 
> My theories on moving forward with cleaning up the database code is as
> follows (these are up for debate, just trying to show my own perspective
> here):
> 
> 1. take another stab at nhibernate. There were issues with mono when
> this was attempted 6 months ago which I'm hoping we can get past. I'm
> going to do some experiments here this week to see if nhibernate will
> work for us.
 
Nhibernate definitely deserve a try. I dont know about it, and I'm 
impatient to watch and learn it.
 
> 2. Move out the ADO.NET implementations. The approach we should take is
> one similar to the MySQL Assets plugin where the SQL definitions are
> done in a seperate resource file. We can do upgrades via this model as
> well.
 
I will continue this way, and maybe patch something to Mantis as sure I am
sure to have something that runs good enough.
Meanwhile, I will also try to follow the regular updates that are made in 
the current evolving libraries, focusing particularly on the MySQL 
implementation which seems to be the best one.

Again, thanks for your feedback,

Cheers,
Laurent.

_________________________________________________________________
Nouveau ! Créez votre profil Messenger !
http://home.services.spaces.live.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080108/f34b26fc/attachment-0001.html>