I`d like to see the facts based on that assumption. I`ve worked with NHibernate in web solutions for years and there hasn`t been any lack of performance. I had a one year pause with Hibernate and it seems during it there has been great development, nhibernate own cache etc.
If we assume that NHibernate is currently slower there is sure a plenty of ways to get it faster. Indexing, caching, bulk fetches to mention few. Best, - Antti 2009/2/18 Melanie <[email protected]> > NHibernate has, in tests, been significantly slower than native > implementations. > > Melanie > > Antti Kokko wrote: > > Trying to catch up but anyway what I think in general is that the whole > > database schema is not the best in terms of coherence, associations etc. > For > > me it seems that at first came all functionality and them came the > database > > solutions. The structure feels is "broken" but I understand it because of > > grid mode etc. > > > > What I`d like to see is simply one db solution which covers mysql, mssql > and > > sqlite and that is most propably NHibernate. Why do all the updates to > all > > interface implementing classes instead of doing it only in one place. I > > think this could save some serious time. > > > > However I try to get to the asset discussion: > > > > First of all I really like the way of Cable Beach and truly hope this all > is > > going to distributed asset system. One of the biggest issues is cache, > > external cache etc. If we have e.q. publisher who wants to update an > object > > in Cable Beach which is already used in sim1 and sim2, how we send the > > update to all caches? How I have understood it the current system is a > kind > > of trade-off and actually new object is created instead of updating the > > existing one. On the database side I`d definitely like to see not a new > > object but an update. What I`ve heard the cache issues are long discussed > > and not easy to resolve and we definitely need a further discussion about > > along with Cable Beach or any distributed asset system. After all why I > > couldn`t have an apache web server somewhere where my asset, avatar, > avatar > > appearance are. > > > > Having several asset storages distributed all over the web we need an > UUID > > for the asset but we are going to need of course an URL as key too. That > is > > definitely one issue. > > > > Best, > > > > - Antti > > > > 2009/2/17 Charles Krinke <[email protected]> > > > >> Dear Teravus: > >> > >> No problem. The key point I was trying to make is that as time goes on > we > >> seem to be increasing exponentially the storage requirements in the > UGAIM > >> assets table. The terrainImage entry was an example of of an 'asset' > that is > >> a little different in perception then say, a texture covering a face of > a > >> prim. > >> > >> This example was intended for us to think about those 'assets' which can > be > >> pruned on a regular basis so that our ability from the UGAIM viewpoint > to > >> find and retrieve an asset in a timely manner does not get so long as to > >> make our sims performance degraded. > >> > >> Charles > >> > >> ------------------------------ > >> *From:* Teravus Ovares <[email protected]> > >> *To:* [email protected] > >> *Sent:* Tuesday, February 17, 2009 6:39:52 AM > >> *Subject:* Re: [Opensim-dev] Please do not revert fixes without careful > >> comtemplation > >> > >> I thought it prudent to point out that the following statement is 100% > >> fiction; > >> > >> " 2. We have a significant number of assets of each and every edit of > >> terrain, where only the very last one is accessible" > >> > >> What I think you meant to say was, > >> > >> "2. Every two days each region generates a new map tile image and > >> names it terrainImage. These do eventually add up" > >> > >> Best Regards > >> > >> Teravus > >> > >> On Tue, Feb 17, 2009 at 9:31 AM, Stefan Andersson < > [email protected]> > >> wrote: > >> > > >> >> > 1. We have a significant number of assets whose name is "blank" > that > >> are > >> >> > created with a default constructor. And I suspect are never > >> accessible. > >> >> > >> >> In fact, this field has always seemed redundant to me since the user > >> only > >> >> ever manipulates assets by their inventory > >> >> name, which is entirely separate from the asset name. The asset name > is > >> >> never visible to the user (and afaik is not > >> >> used anywhere else in the code). > >> >> > >> >> At one point I thought about proposing to remove it. Possibly this > issue > >> >> should be revisited. > >> > > >> > I believe it's kept there just as a convenience - to be able to get > some > >> > kind of semantics, not necessarily exact, when browsing the table. > >> > > >> >> > 2. We have a significant number of assets of each and every edit of > >> >> > terrain, where only the very last one is accessible. > >> >> > >> >> Yes, this does seem wasteful to me since old terrain assets are not > used > >> >> by anything, afaik. > >> > > >> > I have proposed a number of times that we could have a virtual > asset_key > >> as > >> > well as an asset_id - so that things that would rewrite assets could > use > >> the > >> > asset_key as an aux method to actually try to overwrite the asset. In > the > >> > terrain case, the asset would be overwritten by key, not by id. This > >> would > >> > allow us to implement a number of parallell schemas where some assets > >> would > >> > be overwritten (asset_key = asset_id) and some where we would keep a > >> history > >> > (only asset_key) and some where doing either or would be configurable. > >> > > >> >> > 3. We have a significant number of assets of each and every text > edit > >> >> > for each and every textual assets. Where only the last one should > be > >> >> > accessible. > >> >> > >> >> Unfortunately, this is not the case. For instance, imagine that you > >> create > >> >> a script in your inventory. You drag this > >> >> script into a region object. At this point, both the entry in your > >> >> inventory and the entry in the region point to the > >> >> same textual asset. > >> >> > >> >> But then you edit the script in your inventory. After the edit it > points > >> >> to a new asset containing the edited text. > >> >> However, the region object is still pointing to the old script asset. > So > >> >> we need to keep both the old and new textual > >> >> assets. > >> > > >> > Not to mention the fact that the viewer caches stuff. > >> > > >> >> However, you're right in that textual assets which are never used > >> >> elsewhere (i.e. are intermediate edits that never get > >> >> dragged into an object, given to someone else, or otherwise > transmitted) > >> >> might possibly be eliminated with some > >> >> sufficiently careful scheme. > >> > > >> > Binary de-duplication and added semantics in the form of 'key' or > 'class' > >> > would probably go a long way. > >> > > >> >> > Its a bit like collecting every scrap of paper ever written with > >> either > >> >> > text or binary glyphs and putting them in a big filing cabinet. > >> >> > > >> >> > After a while, finding the ones that are "interesting" in a > "timely" > >> >> > manner starts to get a little "challenging". > >> > > >> > Let's keep the shining torch of this discussion burning. > >> > > >> > /Stefan > >> > > >> > > >> > _______________________________________________ > >> > Opensim-dev mailing list > >> > [email protected] > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > > >> > > >> _______________________________________________ > >> Opensim-dev mailing list > >> [email protected] > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> [email protected] > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
