Add versioning, created updated times for notification templates schema

[darshanasbg]

Proposed changes in this pull request

$subject. Related to,

• Maintain created & updated time and the schema version for notification templates product-is#21887

When should this PR be merged

Immediate

Follow up actions

Merge,

• Add capability to maintain version, created_at & updated_at values wso2-extensions/identity-event-handler-notification#295
• Update framework & event handler notification versions product-is#22033

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 45.26%. Comparing base (12f8728) to head (84027a3).
Report is 10 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##             master    #6171   +/-   ##
=========================================
  Coverage     45.26%   45.26%           
+ Complexity    13819    13818    -1     
=========================================
  Files          1615     1615           
  Lines        100526   100528    +2     
  Branches      17307    17308    +1     
=========================================
+ Hits          45502    45509    +7     
+ Misses        48329    48323    -6     
- Partials       6695     6696    +1     

Flag	Coverage Δ
unit	27.81% <ø> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Thumimku]

Suggested change

	CREATED_AT TIMESTAMP NOT NULL,
	CREATED_AT TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
	UPDATED_AT TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

Some DB support have DEFAULT and ON_UPDATE support, we can use that if applicable?

[darshanasbg]

Whether these values needs to be managed from the db side or the application side is something we have to decide here..

I also thought to handle this from the db level as per ee52c3c

But bit further check on things, I choose maintaining these values at the application level due to following reasons:

1. There as data format difference between databases.. But this is a minor reason, since the difference was only at the millisecond levels
2. Different db impls have their own way of doing this, there is no constant one way to do across this in different db types and versions.. and when consider an example on how these going to be effected with the data replications with the things like DR or multi-regions is something we don't have in-depth expertise with the various database types we need to support...

So going down with the path of depending on db to maintain these records increase the complexity of the solution, reduce the maintainability product. So selected the handling at the application level data handling to make things simple.

If we are concerned about, each developer to having to handle this at each of their DAO impls, we can avoid such duplicated efforts by centralizing maintaining this logic in a place like jdbcTemplates.

[omindu]

+1 for the approach suggested initially in this PR based on @darshanasbg's reasoning

How were we historically handling the created times? The above concerns should be there for those as well

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud