[DISCUSSION] Management of the database's "VIEW"s

2023-02-06 Thread Daniel Augusto Veronezi Salvador

Hello guys,

I would like to open a discussion on our current management of the database's 
"VIEW"s.

Currently, we have to look at the changes in the previous "schema" files and replicate the whole "CREATE 
VIEW" command in the current "schema" file, modifying what we need (adding/removing columns, and so on). This 
process makes the changes in a "VIEW" to be distributed through several files, increasing the number of lines modified 
for simple changes (e.g.: for adding a single field to the "VIEW" result we need to replicate the whole command); thus, 
making it difficult to maintain and track.

With that in mind, I had some ideas of how we can improve this process. The proposal is: instead of 
adding the changes to the current "schema" file, we create unique files for each 
"VIEW" and manage them; more detailed:
1. under the directory "db", where the "schema" files are, we would create a 
sub-directory called "views";
2. in the sub-directory "views", we would create a file for each "VIEW", named with the 
"VIEW" name (for instance, "cloud.network_offering_view.sql");
3. in the "VIEW" file, we would put the "DROP VIEW" command, followed by the "CREATE VIEW" command, 
just as we do in the "schema" file; for instance, the content of file "cloud.network_offering_view.sql" would 
be:

```
DROP VIEW IF EXISTS `cloud`.`network_offering_view`;

CREATE VIEW `cloud`.`network_offering_view` AS
SELECT
`network_offerings`.`id` AS `id`,
`network_offerings`.`uuid` AS `uuid`,
`network_offerings`.`name` AS `name`,

```

4. then, after each version upgrade, in Java we execute all the files in the sub-directory 
"views"; this way, if a "VIEW" changed, it would be recreated with the new 
changes; otherwise, it would be only recreated as is;

That would allow us to easily track "VIEW" modifications, as we would just change the "VIEW" 
declaration in the same file, instead of re-declaring the whole "VIEW" in a different file; and we would have 
a better history of the changes. Also, we would not need to migrate all "VIEW"s right away; we could migrate 
as we change them.

Please, let me know your thoughts about the proposal.

Best regards,
Daniel Salvador (gutoveronezi)


[GitHub] [cloudstack-kubernetes-provider] davidjumani commented on pull request #41: Allow case insensitive vm names while creating lb rules

2023-02-06 Thread via GitHub


davidjumani commented on PR #41:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/pull/41#issuecomment-1420194318

   Just click the merge button :)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [cloudstack-kubernetes-provider] rohityadavcloud commented on pull request #41: Allow case insensitive vm names while creating lb rules

2023-02-06 Thread via GitHub


rohityadavcloud commented on PR #41:
URL: 
https://github.com/apache/cloudstack-kubernetes-provider/pull/41#issuecomment-1420328483

   I meant to say, in terms of testing and review @davidjumani I'll merge this 
however as changes make sense to me and Build has passed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[GitHub] [cloudstack-kubernetes-provider] rohityadavcloud merged pull request #41: Allow case insensitive vm names while creating lb rules

2023-02-06 Thread via GitHub


rohityadavcloud merged PR #41:
URL: https://github.com/apache/cloudstack-kubernetes-provider/pull/41


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@cloudstack.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org