Um, 1.0 to 1.1 seems like the right time to break an api if you are going to eventually. Better if it were a 1.x to 2.x, but certainly it's not a 1.0.12 to 1.0.13 situation. I think it woudl be hard to argue on a purely needs basis. Apache as a whole is approaching 500,000 commits in their subversion repo over its lifetime, which couldn't amount to more than 4x results in any table, could it? What are the real characteristics of how many keys are generated given a repo of a certain size, etc?
Besides, the database will be broken and need migration or re-building between 1.0.3 and 1.1 anyway, so that's no barrier. If we're running 1.1-SNAPSHOTs, well, guess what... they're snapshots - not guaranteed to function the same upon release. Not reasons to do it, mind you, just rebuttals to some reasons to not do it. Christian. Trygve Laugstøl wrote: > Rahul Thakur wrote: >>>> 'int' ids are now converted to 'long' across the project and to >>>> allow really large values. This should cater to scenarios where the >>>> id generation could be started from an arbitrary large value. >>> >>> Won't this break the API? >> >> Yep, it would. >> >>> >>> What is the use case where 4 billion IDs isn't sufficient? >> >> 2 billion you mean :-). But this also more of something that I have >> noticed 'traditionally' that ids are specified as long and stored as >> bigints in database > > No, 4 billion. an int is +-2billion. Anyway, just because longs are > more traditionally used that is not a good enough reason to switch to > longs and break the API to me. > > -- > Trygve > -- *christian** gruber + process coach and architect* *Israfil Consulting Services Corporation* *email** [EMAIL PROTECTED] + bus 905.640.1119 + mob 416.998.6023*
