Just thought of pointing out that there is an option of optimizing UUIDs stored in the DB to make them easier to sequence and reduce storage size[1]. Though I doubt we will have such high volumes of data in a given DB instance with the new C5 architecture so don't think we need to go down this route.
+1 for a perf test as Bhathiya suggested to make sure. [1] https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ On 19 November 2016 at 16:58, Lahiru Cooray <lahi...@wso2.com> wrote: > Hi Bathiya/Jo, > Thanks for the valuable information. > +1 for UUID as the PK > > > On Sat, Nov 19, 2016 at 3:41 PM, Joseph Fonseka <jos...@wso2.com> wrote: > >> >> >> On Sat, Nov 19, 2016 at 3:38 PM, Joseph Fonseka <jos...@wso2.com> wrote: >> >>> Hi All >>> >>> Another most obvious advantage of using UUIDs would that it will >>> simplify import/export of APIs. I am +1 for using UUIDs as primary keys. >>> >> >> In a more correct term UUIDs will simplify managing APIs cross >> environments. >> >> >>> >>> Cheers >>> Jo >>> >>> On Sat, Nov 19, 2016 at 12:42 PM, Bhathiya Jayasekara <bhath...@wso2.com >>> > wrote: >>> >>>> Hi Lahiru, >>>> >>>> One of the reasons to expose UUIDs instead of auto increment IDs in >>>> REST resources is that if we expose auto increment ID, we unwillingly >>>> expose certain internal information like how many resources we have in our >>>> system and the pattern how we store these resources. That information can >>>> be used as vulnerabilities for security attacks. Due to the same reason, >>>> it's kind of a standard to use UUIDs instead of auto increment IDs in REST >>>> world. You can find some detailed explanations about that on the web[1][2]. >>>> >>>> [1] http://stackoverflow.com/questions/12378220/api-design-a >>>> nd-security-why-hide-internal-ids >>>> [2] http://blogs.perl.org/users/ovid/2014/11/stop-putting-auto-i >>>> ncrement-ids-in-urls.html >>>> >>>> Thanks, >>>> Bhathiya >>>> >>>> On Sat, Nov 19, 2016 at 12:12 PM, Lahiru Cooray <lahi...@wso2.com> >>>> wrote: >>>> >>>>> Hi Uvindra, >>>>> The reason you mentioned is: >>>>> "Having a UUID for this purpose means that end users cannot guess the >>>>> possible unique identity of other entities, which is possible if we >>>>> exposed >>>>> an integer based identifier." >>>>> >>>>> What is the purpose of having a non guessable Id here? Anywhere the >>>>> user who has permissions to invoke api's can get the uuid list or simply >>>>> can view in the Store/Publisher UI. If there are any more implementation >>>>> constraints (eg: user should be able to delete api's only in his tenant >>>>> domain, etc) should be handle internally. >>>>> >>>>> What I'm trying to highlight is, we should only move to a hybrid >>>>> approach only if there's a valid use case. Else it's less complex if we >>>>> can >>>>> move only with the auto increment Id. >>>>> >>>>> [Solution we discuss here can also be reused in AppM c5 upgrade] >>>>> >>>>> >>>>> >>>>> On Fri, Nov 18, 2016 at 11:27 PM, Uvindra Dias Jayasinha < >>>>> uvin...@wso2.com> wrote: >>>>> >>>>>> We expose the unique UUID of a given artifact to the end user via >>>>>> REST APIs. You can see how this is used in the REST API docs[1]. We cant >>>>>> use the auto increment ID for this purpose for the reasons I mentioned >>>>>> earlier. >>>>>> >>>>>> [1] https://docs.wso2.com/display/AM200/apidocs/publisher/index.html >>>>>> >>>>>> On 18 November 2016 at 22:48, Lahiru Cooray <lahi...@wso2.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I was under the impression that the UUID was used as a result of >>>>>>> having registry and UUID was used to map the registry resource. Pls >>>>>>> correct >>>>>>> me if I'm wrong. >>>>>>> >>>>>>> When the registry is no longer present, I don't see a real use case >>>>>>> of going for a hybrid approach. Either we could use UUID as a PK or an >>>>>>> auto >>>>>>> increment ID. >>>>>>> >>>>>>> In this case +1 for an auto increment ID as the PK. >>>>>>> Reasons: easy to debug manually/ easy to sort by id/ save space >>>>>>> >>>>>>> On Fri, Nov 18, 2016 at 9:34 PM, Uvindra Dias Jayasinha < >>>>>>> uvin...@wso2.com> wrote: >>>>>>> >>>>>>>> We already have a UUID column for few tables such as AM_API and >>>>>>>> AM_APPLICATION which is used to uniquely identify a record. The reason >>>>>>>> why >>>>>>>> we have a UUID column is because it is the unique identifier that we >>>>>>>> expose >>>>>>>> to the end user. Having a UUID for this purpose means that end users >>>>>>>> cannot >>>>>>>> guess the possible unique identity of other entities, which is >>>>>>>> possible if >>>>>>>> we exposed an integer based identifier. >>>>>>>> >>>>>>>> However at table level we were still maintaining an auto >>>>>>>> incrementing primary key. So the UUID was used externally but the >>>>>>>> integer >>>>>>>> key was used privately to maintain foreign key relationships within the >>>>>>>> schema. >>>>>>>> >>>>>>>> We first thought it might be a good idea to dispense of the auto >>>>>>>> incrementing primary key and use the UUID as the primary key itself >>>>>>>> since >>>>>>>> it seemed like we had two columns that served somewhat duplicate >>>>>>>> purposes. >>>>>>>> But I have been doing some research regarding this and have found that >>>>>>>> the >>>>>>>> industry is divided a bit regarding this point. >>>>>>>> >>>>>>>> These links advocate UUIDs as primary keys >>>>>>>> https://blog.codinghorror.com/primary-keys-ids-versus-guids/ >>>>>>>> https://www.clever-cloud.com/blog/engineering/2015/05/20/why >>>>>>>> -auto-increment-is-a-terrible-idea/ >>>>>>>> >>>>>>>> These links recommend auto incrementing integers as primary keys >>>>>>>> http://stackoverflow.com/questions/404040/how-do-you-like-yo >>>>>>>> ur-primary-keys/404057#404057 >>>>>>>> http://stackoverflow.com/questions/829284/guid-vs-int-identity >>>>>>>> >>>>>>>> We can still continue with our hybrid approach of having both an >>>>>>>> auto incriminating integer as primary key and using the UUID for >>>>>>>> external >>>>>>>> interactions, whihc seems to be also used by some to get the best of >>>>>>>> both >>>>>>>> worlds. >>>>>>>> >>>>>>>> >>>>>>>> So how should we proceed? >>>>>>>> >>>>>>>> -- >>>>>>>> Regards, >>>>>>>> Uvindra >>>>>>>> >>>>>>>> Mobile: 777733962 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Lahiru Cooray* >>>>>>> Software Engineer >>>>>>> WSO2, Inc.;http://wso2.com/ >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> Mobile: +94 715 654154 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Uvindra >>>>>> >>>>>> Mobile: 777733962 >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Lahiru Cooray* >>>>> Software Engineer >>>>> WSO2, Inc.;http://wso2.com/ >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile: +94 715 654154 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Bhathiya Jayasekara* >>>> *Senior Software Engineer,* >>>> *WSO2 inc., http://wso2.com <http://wso2.com>* >>>> >>>> *Phone: +94715478185 <%2B94715478185>* >>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >>>> <http://www.linkedin.com/in/bhathiyaj>* >>>> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >>>> *Blog: http://movingaheadblog.blogspot.com >>>> <http://movingaheadblog.blogspot.com/>* >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> -- >>> *Joseph Fonseka* >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> mobile: +94 772 512 430 >>> skype: jpfonseka >>> >>> * <http://lk.linkedin.com/in/rumeshbandara>* >>> >>> >> >> >> -- >> >> -- >> *Joseph Fonseka* >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 772 512 430 >> skype: jpfonseka >> >> * <http://lk.linkedin.com/in/rumeshbandara>* >> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Lahiru Cooray* > Software Engineer > WSO2, Inc.;http://wso2.com/ > lean.enterprise.middleware > > Mobile: +94 715 654154 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
