Entity with GUID Primary key/Identifier 

Entity with GUID Primary key/Identifier 

  
If you have ever used GUID for your entity  Primary key/Identifier, you might be aware that everytime you want to create a new record, you have to manually assign the GUID.

Is there an easier way to do this? having to manually assign GUID for each and every record is very time consuming process. If its just a hand full of tables thats fine, but when its 200+ tables, time should be spent on other task.

Its just like if you didnt have auto increment integer identifiers, it would become a problem for you too?


Hi Robert,

I can't think of an easier way of assigning the PK as GUID to your entities... You've probably already done a set of actions around your entities so that no one uses the built in ones and don't repeat any of that boring work.

I can see your pain of having to create this actions, but it's a one time only work. I can see you easily investing half day work just to build this, but you'll defnitly gain it in the long term.

Cheers
Pedro Cardoso
Pedro

If you could fix it it would be great!

You could either...

1) Add a new data type "GUID".
When a GUID datatype is assigned to an entityattribute and that attribute is set to auto assign GUID. Outsystems will auto assign the attribute with a GUID value.

Scaffolding, will also be able to determine the identifier is using a GUID data type, therefore scaffolding will auto assign GUID, and no longer prompt the user to manually enter a identifier via form.

2) Instead of adding GUID as a data type, detect the entity identifier has been assigned with datatype "text" 
When scaffolding is used, the default behaviour is to assign a GUID value.

BTW: Natural keys vs surrogate key -You could always post a question on stackoverflow, and tell them you want to create a database table, with the primary key data type set to varchar.  A user will be able to manually input the primary key in to a form and this would create a table record, - would this be a good idea or a bad idea?  


Hello Robert,

It could be a good solution. The only thing that I can tell you is to add it as an ideia and who knows, maybe it gets implemented!

You really lost me with that "Natural keys vs surrogate key". What are asking?!

Pedro


Pedro Cardoso wrote:
Hello Robert,

It could be a good solution. The only thing that I can tell you is to add it as an ideia and who knows, maybe it gets implemented!

Pedro

 
It was submitted by me 4 years ago http://www.outsystems.com/ideas/935/auto-guid-for-entity-primary-key-id 
 
Pedro Cardoso wrote:
You really lost me with that "Natural keys vs surrogate key". What are asking?!
When an entity (primary key) identifier has been assigned with a text data type.

Scaffolding, automatically assumes the user would like to fill in his own the primary key identifier! in this case he will most likely enter a natural key identifier that has meaning to him or the data that is stored in the entity/database table. For example "Apple", "apple", "apples", "(apple)", "maçã" (apple in portuguese), "applle" (spelling mistake) etc, these are all valid text identifier inputs, for the same record.        

A primary key identifier key with a meaningful value is known as natural key identifier! and its often created by the end user.^

On the other hand outsystems scaffolding can set good practice using GUID surrogate keys when an identifier is set up with a GUID data type, or when "text" data type is set as the identifier scaffolding can detect this.


Surrogate key is a unique system-wide value, that is generated by the system, and has no semantic meaning, (i.e using GUID as the primary key identifier you are creating surrogate keys)


^Of cause a the developer can fix this issue, but the problem is he will need to fix this type of issue each time scaffolding is used, first the you have to delete the auto generated text field, next manually assign guid for create method (action). Thats not so hard, but if you spent 5 minutes per table fixing this issue, and you have 200 tables you would have wasted 16 hours of your time to fix this simple issue, then have to maintain it (costing more time),

Only when you build an system wide app that uses GUID you would feel the pain, something sounds so simple to fix can actually take up alot of time! It should be built correctly by outsystems scaffolding to begin with.
Robert,

I didn't see you idea, sorry about that. 
I know what a natural key and a surrogate key is, but thanks anyway!

If you're not using natural keys, like social security number or something alike, why are GUID so much better than an auto increment identifier? Are you affraid to go over the limit?


@Pedro, yes going over the limit is the key factor, and being able to merge multiple database is a bonus. Think global SaaS multi tenant app; PayPal processes 10 million transactions a year, in less than one year int32 is max limit is excessed. Amazon processed over 400+ orders a second on Christmas; tweeter 500 million tweets per day; Facebook sends over 1 billion messages per day. Of course before any company reaches 2 billion records there would be alot of other issues that would need to resolve first. Typically an enterprise would take years to reach the limit, a SaaS app can reach the int32 limit within hours and days.
@Robert cool, that explains it. For a large app like the ones mentioned, not even a int64 would help... maybe only a GUID or alike would... thoughts?
Pedro Cardoso wrote:
@Robert cool, that explains it. For a large app like the ones mentioned, not even a int64 would help... maybe only a GUID or alike would... thoughts?
Int64 should be sufficent in 90% of most use cases, however sufficent or not sufficent, GUID should be officially supported as a data type. You have the following advantages
  • You are able to generate GUID offline  
  • You are able to merge and replicate data easily with GUID (int makes it really really hard)
  • Your GUID is unique across applications!
Using GUID in outsystems is extremely painful, theres no official support for GUID, something that outsystems think is easy, actually takes up alot of time, if your just going to work with a few tables, its not a real problem working with GUID. if you have to work with a few hundreds of tables, or even thousands of tables, simply to assign guid itself is a time consuming task - you have to do this everywhere when a "Create" method is used.

Many years later there is still no official guid supported as a data type, its extremely diffcult to communicate a SaaS requirement to outsystems, when outsystems deals with enterprise apps and enterprise business, enterprise customers!
Everything is enterprise, even engineers at outsystems think like an enterprise and dont really understsand SaaS business! Just need experienced engineers in SaaS/cloud business.

First you must understand SaaS apps is completely different! different use case, different business, if you solve scalability for SaaS apps, you solve scalability for enterprise apps aswell, since enterprise apps  data requirements are often a lot smaller than SaaS apps.

Enterprise apps often contains many more features/business logic than a SaaS app, but their data requirements are smaller than SaaS apps. 

Many years ago when outsystems was built, 2 billion records seems like a big number, but then facebook, twitter, instragram etc was born, and now billions is not so big anymore, eBay processes 1 billion transactions per day! so now you see the scale of the problem.

BTW: Over 90% of outsystems customers are enterprise business, therefore 99-100% of outsystems engineers are focused on meeting the needs of enterprise business requirements therefore SaaS business requirements has been neglected for many years. Trying to tell outsystems about this for many years will not make a different. I tried, and I have failed to get outsystems to implement this feature.
I agree that I'd like to see GUID supported as an official data type, and for IDs. We're a SaaS project as well... if we expand to larger markets that have 10x volume as we see now with our current niche market, we will definitely need this.

That said... I don't see this as a HUGE hassle to support/implement myself. We already write create logic for our business logic layer where we'd put this.

J.Ja
ah, this is what i was looking for, but now i see that there is no GUID implimentation.
Eric,

it's in the system espace


The simple fix, having the platform support bigint, has been an idea since November 2010 (http://www.outsystems.com/ideas/557/support-for-bigint-datatype-sql-server ).  This would solve most users issues with large numbers of records without the complexity of using GUID.
BigInt would definitely have a place, but its not a suitable alternative for GUID, specifically for the reasons Robert pointed out:

  • You are able to generate GUID offline  
  • You are able to merge and replicate data easily with GUID (int makes it really really hard)
  • Your GUID is unique across applications!
The sooner the Outsystems community get their head around the evolving nature of SAAS, the better. The SAAS market has the potential to dwaft the enterprise market in terms of application size and user subscriptions. Growth in both areas benefits Outsystems, so its in their best interest to start listening.

Some simple simple enhancements, such as native GUID support and Single User Multi Tenant support would enhance Outsystems position in both the Enterprise and SAAS market.

Having to manually implement these features at the moment takes time away from having the ability to innovate and progress your application. Not to mention the cost of Software Units/Application Objects to manually implement these enhancements.

Mr Chanphakeo has been beating the SAAS drum for a very long time. 
I think we need to join in, so that its loud enough to be heard in the right place.

Correct me if i'm wrong, but isn't Outsystems biggest application at the moment a SAAS application?

Rant over :)