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