Hi James, I'd vote for the hashCode() approach, why:
1) It's the approach already used and widely accepted (for example in Hibernate) 2) using Hibernate (which is what Tapernate is dedicated to) you are advised to implement hashCode() and equals() anyway (according to the Hibernate homepage) so it's no additional expense to use it for Tapernate. Just my two cents... Andreas On 06. Jun 2006 - 08:08:21, James Carman wrote: | For those of you who are using Tapernate (and those of you who have done | something similar in the past), I have a question for you. Currently, the | Tapernate entity squeezer uses an abbreviation for the class name (basically | an integer). However, I was thinking that this might not be a good thing | for external links. What would happen if the application is restarted and | someone has bookmarked an external link? So, I need to come up with a | reliable/repeatable way to "shrink" the entity name down to a small string. | Now, the situation gets even trickier when you consider the fact that your | application may add entity classes between releases. Therefore, I can't | just sort the entity class names and then assign them a number (their index | in a list). I *really* don't want the entire entity name in the URLs. That | would look kind of cheesy. The way I see it, there are some options... | | 1. Use a message digest of the entity name. The message digests would all | be the same length, so we wouldn't have to worry about the URLs "growing" | when the entity name grew. But, there *is* the chance for digest collisions | (digest of entity name A is the same as digest of entity name B). | | 2. Use the hashCode() of the entity name Strings. Again, we've got the | possibility for collisions. | | 3. Just use the "simple" entity name (the part of the name after the last | '.'). I don't think Hibernate requires that you have unique "simple" names | for your entity classes. In practice, this is typically not a problem. | But, in general, it's not a robust solution. | | 4. Just use the entire entity name and don't worry about all of this! | Users can override it if they wish and how they wish. | | I will be creating a service point which does the translation to/from the | entity name abbreviation and users can override it if they want. Which of | these (or if you have other ideas) would be the best "default", though? The | entity squeezer will detect when there is a collision and either throw an | exception or print an error message to the logs (haven't decided yet) to let | you know that you need to come up with a better solution for entity name | abbreviation. | | James --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
