Yes Akalanka, that is one disadvantage that has been highlighted. But going by the fact that the volume of data in a given DB instance reduces drastically in C5 this may not be an issue. But only a perf test with real data will reveal this for sure
On 21 November 2016 at 12:27, Akalanka Pagoda Arachchi <[email protected]> wrote: > 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 <%2B94777118016>* > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
