Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
One of the core developers has tested it. I don't recall who. Any indirection can only slow things, it adds processing overhead. If NHibernate canbe made faster with indexes, than the same indexes will speed up native access even more. I'm happy I finally took the time to get rid of the MySQL ADO.NET wrappers and made the implementation pure native. It is now the thinnest layer possible between the driver module and the application. I, for one, am not interested in using a juggernaut like NHibernate. Melanie Antti Kokko wrote: 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 mela...@t-data.com 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 c...@pacbell.net 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 tera...@gmail.com *To:* opensim-dev@lists.berlios.de *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 ste...@tribalmedia.se 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
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
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 c...@pacbell.net 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 tera...@gmail.com *To:* opensim-dev@lists.berlios.de *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 ste...@tribalmedia.se 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
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
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 Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
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 ste...@tribalmedia.se 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 Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
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 c...@pacbell.net 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 tera...@gmail.com *To:* opensim-dev@lists.berlios.de *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 ste...@tribalmedia.se 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
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hi, One example is here http://realxtendserver.svn.sourceforge.net/. Choose Authentication. There is NHibernateHandler and under that is Bulk. Best, - Antti 2009/2/16 Tommi Laukkanen tommi.s.e.laukka...@gmail.com Hello It would be nice to have somekind of short term solution to fix the current nhibernate asset store implementation so that it works and when cable beach is finalized we can see if we need to do something extra to support that fully. Antti: Can you elaborate with examples or link me to some nhibernate documentation which explains bulk object concept in detail. I don't get the exact implementation details from your mail. By implementation I mean what kind of mapping files you are proposing we would need and how they would be used from code. regards, Tommi ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hence me suggesting stronger hashes - there's no known attacks on anything above or equal to 160bit, plus to calculate an attack you'd have to have the hash of the original to begin with, which shouldn't be something revealed to an end user. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 5:26 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation I see the potential of targeted MD5 collisions as a way to obtain script sources. A saves a script. B creates a targeted collision, which will result in creation of an inventory item refering to A. The data B saves is ignored because of hash equality B then reopens the object and receives A's script source. Melanie Frisby, Adam wrote: You do realise you could just not update the asset. If the hash is the same, then you can just completely ignore the save/update request. That being said, even a targeted collision on MD5 is a 2^58 chance, on SHA256 it's well over 2^128 which makes it pretty much impossible. Frankly it's not something worth concerning oneself over. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 4:45 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009- February/004918.html -- --- --- ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello
That works if we have property accessors directly exposed from AssetBase to
all metadata fields. Then we can write mapping with those accessors and
ignore the metadata aggregate.
regards,
Tommi
On Mon, Feb 16, 2009 at 1:54 PM, Mike Mazur mma...@gmail.com wrote:
Hi,
On Mon, Feb 16, 2009 at 8:38 PM, Tommi Laukkanen
tommi.s.e.laukka...@gmail.com wrote:
It would be nice to have somekind of short term solution to fix the
current
nhibernate asset store implementation so that it works and when cable
beach
is finalized we can see if we need to do something extra to support that
fully.
How would this work as a temporary measure:
class AssetBase
{
private byte [] m_data;
private AssetMetadata m_metadata;
public UUID FullID
{
get { return m_metadata.FullID; }
set { m_metadata.FullID = value; }
}
// etc for the rest of the properties
// we have a method to retrieve the AssetMetadata object
// so we don't also serialize it when sending assets over the wire
public AssetMetadata getMetadata()
{
return m_metadata;
}
public void setMetadata(AssetMetadata metadata)
{
m_metadata = metadata;
}
}
Is there a better way to stop the metadata (property) from being
serialized instead of using the C++-style accessor and mutator?
I can commit this in about 12 hours if it would work. Comments welcome.
Thanks,
Mike
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
___
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Plus you could use those hashes to distribute the assets to several backed databases in similar manner as hashmap works. If a database becomes too full you can always split it to sub databases and move assets there in analogy with hashmap internal datastructure. Basicly all hashmap performance math and algorithms should apply. Do you think this could be workable way of doing asset storage distribution? regards, Tommi On Mon, Feb 16, 2009 at 3:21 PM, Frisby, Adam a...@deepthink.com.au wrote: Hence me suggesting stronger hashes - there's no known attacks on anything above or equal to 160bit, plus to calculate an attack you'd have to have the hash of the original to begin with, which shouldn't be something revealed to an end user. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 5:26 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation I see the potential of targeted MD5 collisions as a way to obtain script sources. A saves a script. B creates a targeted collision, which will result in creation of an inventory item refering to A. The data B saves is ignored because of hash equality B then reopens the object and receives A's script source. Melanie Frisby, Adam wrote: You do realise you could just not update the asset. If the hash is the same, then you can just completely ignore the save/update request. That being said, even a targeted collision on MD5 is a 2^58 chance, on SHA256 it's well over 2^128 which makes it pretty much impossible. Frankly it's not something worth concerning oneself over. Adam -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- boun...@lists.berlios.de] On Behalf Of Melanie Sent: Monday, 16 February 2009 4:45 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text. Melanie Charles Krinke wrote: I am so sorry that we are having communications difficulties. Terrain Images, are, I believe, neither textual nor text. That was just an example. The point is that we need to be careful and consider all the various assets which include a lot more then textures and scripts. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 8:23:16 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Yes, I did forget sounds. Probably because they never reached critical mass on any system I have anything to do with. Though, a lot seem to exist, judged by the number of gestures. As for images, I call them all textures, because any image could be used as a texture. They are all jp2 steams, so even though they may have a different purpose from covering prims, they are technically identical in storage format and type of content, and would be handled the same. Melanie Justin Clark-Casey wrote: Melanie wrote: No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text. Other non-text assets are images that aren't textures and sounds. Melanie Charles Krinke wrote: I am so sorry that we are having communications difficulties. Terrain Images, are, I believe, neither textual nor text. That was just an example. The point is that we need to be careful and consider all the various assets which include a lot more then textures and scripts. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 8:23:16 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
And that I am in 100% agreement on. Melanie Charles Krinke wrote: Well, it really doesnt matter what one calls them. Binary data, text, whatever. The point is that we have a number of issues with our assets table in OpenSim that a bit of thought would help. 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. 2. We have a significant number of assets of each and every edit of terrain, where only the very last one is accessible. 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. 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. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:43:53 PM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Yes, I did forget sounds. Probably because they never reached critical mass on any system I have anything to do with. Though, a lot seem to exist, judged by the number of gestures. As for images, I call them all textures, because any image could be used as a texture. They are all jp2 steams, so even though they may have a different purpose from covering prims, they are technically identical in storage format and type of content, and would be handled the same. Melanie Justin Clark-Casey wrote: Melanie wrote: No. Terrain images are textures. They are assets referring to jp2 streams. That makes them textures. And, AFAIK, all other assets are text. Other non-text assets are images that aren't textures and sounds. Melanie Charles Krinke wrote: I am so sorry that we are having communications difficulties. Terrain Images, are, I believe, neither textual nor text. That was just an example. The point is that we need to be careful and consider all the various assets which include a lot more then textures and scripts. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 8:23:16 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, that was a typo. The correct word was textual. All asset types besides textures are text. Melanie Charles Krinke wrote: Sorry, the other assets are not just small texture data. We have terrainImages, amongst other things. Our assets table in OpenSim contains lots of things including the infamouse blank, so lets look at it in total and not just from the script viewpoint. Course with scripts themselves, we have every edited version of every edited script in addition to every change of every other asset complicating the problem. Charles From: Melanie mela...@t-data.com To: opensim-dev@lists.berlios.de Sent: Monday, February 16, 2009 4:44:56 AM Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Again, I'd like to stress that I believe this is too dangerous to do for anything other than textures. It is also not really needed for things other than textures, since the other assets are comparatively small, textural data. I would not want to risk even the smallest chance of a hash collision on script source. Melanie Stefan Andersson wrote: Coming in a bit from the side here, we have, for some time, discussed to separate out the binary blog out of the metadata for an entirely different reason, namely to be able to weed out binary duplicates. If there was a way for us to separate out the binary parts, into something like 'binaryassetId, hashData[256], binarydata' and then just have the asset table referencing that row, I think it would help a lot. I realize it's a separate discussion, just chipping in my two cents. Best regards, Stefan Andersson Tribal Media AB Date: Sat, 14 Feb 2009 17:49:22 +0200 From: tommi.s.e.laukka...@gmail.com To: mma...@gmail.com CC: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Please do not revert fixes without careful comtemplation Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello, 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? regards, Tommi On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur mma...@gmail.com wrote: Hi, On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. I was hoping not to have to do that. It should be straightforward to support the current AssetBase/AssetMetadata composition in the existing OpenSim data layers, but as sdague warned me earlier, by mapping multiple classes to one table I was entering a world of pain. Seems that's exactly what's happening with NHibernate. The reason I introduced the AssetMetadata class is to supply metadata information only for some requests that Cable Beach, the new asset server, supports. Now I realize that this was probably a premature optimization. Instead of modifying the DB schema, we could have AssetBase inherit from AssetMetadata, as I outlined before[1]. Alternatively, we could get rid of AssetMetadata altogether and store everything in AssetBase as before, splitting out the metadata sometime in the future when a use case warrants it. What do you think? Thanks, Mike [1] https://lists.berlios.de/pipermail/opensim-dev/2009-February/004918.html ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Here is the mantis in question: http://opensimulator.org/mantis/view.php?id=3122 regards, Tommi On Fri, Feb 13, 2009 at 7:25 PM, Dahlia Trimble dahliatrim...@gmail.comwrote: Is there a specific commit or mantis which this is addressing? I'm not aware of which events your message applies to, but I can say in general that I've only seen a code revert when the original changes cripple functionality for other users or imposes a needless barrier on further development, and then the revert only happens after consultation with others had occurred. This is also a fast moving project with many modifications made to the source tree from many authors. Usually if a revert is required it needs to happen quickly otherwise it becomes increasingly difficult to restore the code back to a condition where it would be had the changes not been applied. If the author of the changes had not been available at the time of the decision to revert then notes are added to the mantis containing the patches explaining the situation to the author. On Fri, Feb 13, 2009 at 8:12 AM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: Dear all If you decide to revert fixes the least you can do is to look into them in detail and run the unit tests to make sure that the revert does not make situation worse. This is also part of mutual respect between developers. Some of us are new in the project. Some of us are inexperienced. But all of us have intellect and feelings. Optimally if you find a problem which does not cause problems in the production it is best that the person in blame is given advice and gets to fix the issue himself. This is a large project and we should appreciate everyone who contributes. Motivation is a fragile thing and we should give our peers all the courtesy we can. Let us make the community more enjoyable to everyone. sincerely, Tommi ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Let us assume the best of each other and see what mikem has to say about this first. We should look to resolve any issues like this amicably. Tommi Laukkanen wrote: Here is the mantis in question: http://opensimulator.org/mantis/view.php?id=3122 regards, Tommi On Fri, Feb 13, 2009 at 7:25 PM, Dahlia Trimble dahliatrim...@gmail.com mailto:dahliatrim...@gmail.com wrote: Is there a specific commit or mantis which this is addressing? I'm not aware of which events your message applies to, but I can say in general that I've only seen a code revert when the original changes cripple functionality for other users or imposes a needless barrier on further development, and then the revert only happens after consultation with others had occurred. This is also a fast moving project with many modifications made to the source tree from many authors. Usually if a revert is required it needs to happen quickly otherwise it becomes increasingly difficult to restore the code back to a condition where it would be had the changes not been applied. If the author of the changes had not been available at the time of the decision to revert then notes are added to the mantis containing the patches explaining the situation to the author. On Fri, Feb 13, 2009 at 8:12 AM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com mailto:tommi.s.e.laukka...@gmail.com wrote: Dear all If you decide to revert fixes the least you can do is to look into them in detail and run the unit tests to make sure that the revert does not make situation worse. This is also part of mutual respect between developers. Some of us are new in the project. Some of us are inexperienced. But all of us have intellect and feelings. Optimally if you find a problem which does not cause problems in the production it is best that the person in blame is given advice and gets to fix the issue himself. This is a large project and we should appreciate everyone who contributes. Motivation is a fragile thing and we should give our peers all the courtesy we can. Let us make the community more enjoyable to everyone. sincerely, Tommi ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello, On Sat, Feb 14, 2009 at 1:12 AM, Tommi Laukkanen tommi.s.e.laukka...@gmail.com wrote: If you decide to revert fixes the least you can do is to look into them in detail and run the unit tests to make sure that the revert does not make situation worse. This is also part of mutual respect between developers. Some of us are new in the project. Some of us are inexperienced. But all of us have intellect and feelings. Optimally if you find a problem which does not cause problems in the production it is best that the person in blame is given advice and gets to fix the issue himself. This is a large project and we should appreciate everyone who contributes. Motivation is a fragile thing and we should give our peers all the courtesy we can. Let us make the community more enjoyable to everyone. First, let me apologize for any disrespect you feel, it's definitely unintentional. Second, I need to apologize for ignoring the NHibernate unit tests. My testing script runs whatever is in .nant/local.include and .nant/bamboo.build, and it appears OpenSim.Data.NHibernate.Tests.dll is listed in neither of those. Once the NHibernate tests pass, they should probably be included. Of course this is no excuse for not looking for the NHibernate tests sooner. Finally, you may notice in the commit message that the patch came from another contributor attached to http://opensimulator.org/mantis/view.php?id=3080 who was having issues with NHibernate on startup. I believe this qualifies as a problem in production. The patch fixed that issue. Naturally, had I run the tests like I should have, I would have noticed they fail, and left a comment for the author of the patch accordingly. Please don't regard this as a personal attack. In fact, the commit of the patch was mainly in response to http://opensimulator.org/mantis/view.php?id=3080 rather than imposing my fix to http://opensimulator.org/mantis/view.php?id=3122. Thanks, Mike ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Please do not revert fixes without careful comtemplation
Hello Mike, Thank you for your professional reply. I have tried to reach you in irc immediately after you first commented the mantis but we seem to be in different time zones. The NHibernate unit tests are not in the build as the system is still in experimental state. We have not tried to push them into build yet to avoid hindering the OpenSim development before there is clear indication that NHibernate storage is complete and mature enough to be used in production systems. Currently we are intentionally playing catchup with rest of the systems. I was talking with mikkopa and he suggested we should create two tables to cover AssetBase to solve this issue properly. Namely AssetMetadata for metadata information and AssetData for blobs to avoid situation where we end up accessing also the blob data just to read metadata. He thought you had something like this in mind when you moved metadata fields to aggregate object. This approach would also fix the double id issue which is caused by the fact that nhibernate to my best knowledge does not support reading object primary id from aggregate object. I apologize if I overreacted. It is hard for me to read people and intentions in online environments. regards, Tommi ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
