You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Calls to remote resources and services can fail due to temporary issues like slow network connections or timeouts, as well as longer-lasting problems such as service unavailability. While transient faults can be mitigated using the "Retry pattern," there are cases where continual retries are futile, such as during severe service failures.
4
+
5
+
In such scenarios, it's crucial for applications to recognize when an operation is unlikely to succeed and handle the failure appropriately rather than persistently retrying. Indiscriminate use of HTTP retries can even lead to unintentional denial-of-service attacks within the software itself, as multiple clients may flood a failing service with retry attempts.
6
+
7
+
To prevent this, a defense mechanism like the circuit breaker pattern is essential. Unlike the "Retry pattern" which aims to eventually succeed, the circuit breaker pattern focuses on preventing futile operations. While these patterns can be used together, it's vital for the retry logic to be aware of the circuit breaker's feedback and cease retries if the circuit breaker indicates a non-transient fault.
8
+
9
+
GoFr inherently provides the functionality, it can be enabled by passing circuit breaker configs as options to `AddHTTPService()` method.
10
+
11
+
## Usage
12
+
13
+
```go
14
+
package main
15
+
16
+
import (
17
+
"time"
18
+
19
+
"gofr.dev/pkg/gofr"
20
+
"gofr.dev/pkg/gofr/service"
21
+
)
22
+
23
+
funcmain() {
24
+
// Create a new application
25
+
app:= gofr.New()
26
+
27
+
app.AddHTTPService("order", "https://order-func",
28
+
&service.CircuitBreakerConfig{
29
+
// Number of consecutive failed requests after which circuit breaker will be enabled
30
+
Threshold: 4,
31
+
// Time interval at which circuit breaker will hit the aliveness endpoint.
32
+
Interval: 1 * time.Second,
33
+
},
34
+
)
35
+
36
+
app.GET("/order", Get)
37
+
38
+
// Run the application
39
+
app.Run()
40
+
}
41
+
```
42
+
43
+
Circuit breaker state changes to open when number of consecutive failed requests increases the threshold.
44
+
When it is in open state, GoFr makes request to the aliveness endpoint (default being - /.well-known/alive) at an equal interval of time provided in config.
45
+
46
+
To override the default aliveness endpoint [refer](/docs/advanced-guide/monitoring-service-health)
Copy file name to clipboardExpand all lines: docs/advanced-guide/handling-data-migrations/page.md
+58-20Lines changed: 58 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,28 +1,22 @@
1
1
# Handling Data Migrations
2
2
3
-
Gofr supports data migrations for MySQL and Redis which allows to alter the state of a database, be it adding a new column to existing table or modifying the data type of an existing column or adding constraints to an existing table, setting and removing keys etc.
4
-
5
-
**How Migrations help?**
6
-
7
-
Suppose you manually edit fragments of your database, and now it's your responsibility to inform other developers to execute them. Additionally, you need to keep track of which changes should be applied to production machines in the next deployment.
8
-
9
-
GoFr maintains the table called **gofr_migration** which helps in such case. This table tracks which migrations have already been executed and ensures that only migrations that have never been run are executed. This way, you only need to ensure that your migrations are properly in place. ([Learn more](https://cloud.google.com/architecture/database-migration-concepts-principles-part-1))
3
+
Suppose you manually make changes to your database, and now it's your responsibility to inform other developers to execute them. Additionally, you need to keep track of which changes should be applied to production machines in the next deployment.
4
+
Gofr supports data migrations for MySQL, Postgres and Redis which allows to alter the state of a database, be it adding a new column to existing table or modifying the data type of existing column or adding constraints to an existing table, setting and removing keys etc.
10
5
11
6
## Usage
12
7
13
-
We will create an employee table using migrations.
14
-
15
8
### Creating Migration Files
16
9
17
10
It is recommended to maintain a migrations directory in your project root to enhance readability and maintainability.
18
11
19
12
**Migration file names**
20
13
21
-
It is recommended that each migration file should be numbered using the unix timestamp when the migration was created, This helps prevent numbering conflicts when working in a team environment.
14
+
It is recommended that each migration file should be numbered in the format of *YYYYMMDDHHMMSS* when the migration was created.
15
+
This helps prevent numbering conflicts and allows for maintaining the correct sort order by name in different filesystem views.
22
16
23
17
Create the following file in migrations directory.
@@ -78,9 +72,6 @@ Migrations will run in ascending order of keys in this map.
78
72
package main
79
73
80
74
import (
81
-
"errors"
82
-
"fmt"
83
-
84
75
"gofr.dev/examples/using-migrations/migrations"
85
76
"gofr.dev/pkg/gofr"
86
77
)
@@ -101,9 +92,56 @@ func main() {
101
92
When we run the app we will see the following logs for migrations which ran successfully.
102
93
103
94
```bash
104
-
INFO [16:55:46] Migration 1708322067 ran successfully
95
+
INFO [16:55:46] Migration 20240226153000 ran successfully
105
96
```
106
97
107
98
108
99
109
100
101
+
GoFr maintains the records in the database itself which helps in tracking which migrations have already been executed and ensures that only migrations that have never been run are executed.
102
+
This way, you only need to ensure that your migrations are properly in place. ([Learn more](https://cloud.google.com/architecture/database-migration-concepts-principles-part-1))
103
+
104
+
## Migration Records
105
+
106
+
**SQL**
107
+
108
+
Migration records are stored and maintained in **gofr_migrations** table which has the following schema:
109
+
110
+
{% table %}
111
+
* Field
112
+
* Type
113
+
---
114
+
* version
115
+
* bigint
116
+
---
117
+
* method
118
+
* varchar(4)
119
+
---
120
+
* start_time
121
+
* timestamp
122
+
---
123
+
* duration
124
+
* bigint
125
+
---
126
+
{% /table %}
127
+
128
+
**REDIS**
129
+
130
+
Migration records are stored and maintained in a Redis Hash named **gofr_migrations** where key is the version and value contains other details in JSON format.
131
+
132
+
Example :
133
+
134
+
Key : 20240226153000
135
+
136
+
Value : {"method":"UP","startTime":"2024-02-26T15:03:46.844558+05:30","duration":0}
137
+
138
+
Where,
139
+
140
+
**Version** : Migration version is the number provided in the map, i.e. sequence number.
141
+
142
+
**Start Time** : Time when Migration Started in UTC.
143
+
144
+
**Duration** : Time taken by Migration since it started in milliseconds.
145
+
146
+
**Method** : It contains the method(UP/DOWN) in which migration ran.
0 commit comments