Hi Uvindra, One aspect to keep in mind is that if you have a lot of foreign key references referring this table, all those tables will have a UUID if you choose UUID as the primary key. This might affect the storage space and indexing of those tables as well.
Thanks, Akalanaka. On Sun, Nov 20, 2016 at 6:20 PM, Uvindra Dias Jayasinha <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> wrote: >> >>> >>> >>> On Sat, Nov 19, 2016 at 3:38 PM, Joseph Fonseka <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> >>>>>>> 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 < >>>>>>>> [email protected]> 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 >>>>>>>>> [email protected] >>>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Uvindra >>>>>>> >>>>>>> Mobile: 777733962 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> 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 >>>>> [email protected] >>>>> 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 >>> [email protected] >>> 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 >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Uvindra > > Mobile: 777733962 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Darshana Akalanka Pagoda Arachchi,* *Senior Software Engineer, WSO2* *+94777118016*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
