continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <>
Subject Re: [vote] merge id-refactor branch changes
Date Wed, 24 Jan 2007 14:51:24 GMT
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. 


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** + bus 905.640.1119 + mob 416.998.6023*

View raw message