Hello,<br><br> With NHibernate you can always fetch bulk objects from database. AssetBase has about 10 columns and in case you just need the metadata do a BulkAssetData which only has the metadata and maybe UUID. Then fetch just those fields and convert the object to BulkAssetData. So in this case always keep the whole assetdata in the database and when fething AssetMetaData do a bulk object fetch and cast it to AssetMetaData. This bulk stuff speeds up to database handling since instead of e.q. fething the whole user profile just fetch the columns you need cast to a bulkobject and then you can handle the object in object-oriented manner. There is no need for foreach datarows or similar.<br>
<br> I hope that makes sense.<br><br>Best,<br><br> - Antti<br><br><div class="gmail_quote">2009/2/14 Tommi Laukkanen <span dir="ltr"><<a href="mailto:tommi.s.e.laukkanen@gmail.com">tommi.s.e.laukkanen@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>Hello,</div>
<div> </div>
<div>On second though we could keep the current structure and expose all fields also through AssetBase properties. Then we could save / load the AssetBase with nhibernate as a single object and leave out the Metadata property from NHibernate mapping. Does this sound good?</div>
<div> </div>
<div>regards,</div>
<div>Tommi<font color="#888888"><br><br></font></div><div><div></div><div class="Wj3C7c">
<div class="gmail_quote">On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur <span dir="ltr"><<a href="mailto:mmazur@gmail.com" target="_blank">mmazur@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Hi,<br><br>On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen<br>
<div><<a href="mailto:tommi.s.e.laukkanen@gmail.com" target="_blank">tommi.s.e.laukkanen@gmail.com</a>> wrote:<br></div>
<div>> I was talking with mikkopa and he suggested we should create two tables to<br>> cover AssetBase to solve this issue properly. Namely AssetMetadata for<br>> metadata information and AssetData for blobs to avoid situation where we end<br>
> up accessing also the blob data just to read metadata.<br><br></div>I was hoping not to have to do that.<br><br>It should be straightforward to support the current<br>AssetBase/AssetMetadata composition in the existing OpenSim data<br>
layers, but as sdague warned me earlier, by mapping multiple classes<br>to one table I was entering a world of pain. Seems that's exactly<br>what's happening with NHibernate.<br><br>The reason I introduced the AssetMetadata class is to supply metadata<br>
information only for some requests that Cable Beach, the new asset<br>server, supports. Now I realize that this was probably a premature<br>optimization.<br><br>Instead of modifying the DB schema, we could have AssetBase inherit<br>
from AssetMetadata, as I outlined before[1]. Alternatively, we could<br>get rid of AssetMetadata altogether and store everything in AssetBase<br>as before, splitting out the metadata sometime in the future when a<br>use case warrants it.<br>
<br>What do you think?<br><br>Thanks,<br>Mike<br><br><br>[1] <a href="https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html" target="_blank">https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html</a><br>
</blockquote></div><br>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br>