Implements transaction

[joelmdesouza]

Implements transaction support, at the packet level.
Implemented only for Delete yet so we can discuss the way forward.
@felipeweb @crgimenes @avelino

[avelino]

team, what's your opinion?

[avelino]

I prefer explicit name, example GetTransaction

[crgimenes]

+1 to GetTransaction

[fabriziomello]

Personally I don't see any advantage to run single SQL commands inside a explicit transaction block... in PostgreSQL when you execute, for example an INSERT, it will be executed inside a implicit transaction. Actually all statements runs inside transactions in PostgreSQL. Implement it in this way just add unnecessary complexity and more round trips on code.

[joelmdesouza]

@fabriziomello

The implementation is to perform multiple actions on a transaction.
Example:

tx, _ := adapter.GetTx()
sc := dbAdapter.DeleteTx(tx, `DELETE 1 ...`, ...)
...
sc = dbAdapter.DeleteTx(tx, `DELETE 2 ...`, ...)
...
tx.Commit()

[joelmdesouza]

Rename from GetTX to GetTransaction.
Implemented transaction in Insert, Update, Delete methods.
Is this a good way?
Anyone have any suggestions?

[avelino]

followed pattern names (get like):

• InsertTx > InsertTransaction
• UpdateTx > UpdateTransaction
• DeleteTx > DeleteTransaction

[joelmdesouza]

@avelino
GetTransaction returns a transaction.
Other methods use a transaction.
We keep the InsertTransaction pattern or we use InsertWithTransaction.

[avelino]

My opinion InsertWithTransaction

Team help pls

[crgimenes]

I also prefer InsertWithTransaction.
More explicit is always better.

[fabriziomello]

IMHO I didn't like the idea of create other DML methods for transaction... is more simple create new methods just for BEGIN, COMMIT and ROLLBACK and then internally perform the properly checks to make sure we're inside a transaction... or maybe I missed something.

[joelmdesouza]

@fabriziomello
The reason for creating new methods is not to break applications that are already using the pREST as a package. Because you would have to change the signature of the method to receive a transaction as a parameter.
What I did was to encapsulate the logic of delete in a private method.
So for example, Insert calls it by providing a connection to the database, and InsertWithTransaction calls it by providing the transaction it received as a parameter.

[joelmdesouza]

@fabriziomello
Example:

func (adapter *Postgres) Delete(SQL string, params ...interface{}) (sc adapters.Scanner) {
	db, err := connection.Get()
	if err != nil {
		log.Println(err)
		sc = &scanner.PrestScanner{Error: err}
		return
	}
	sc = adapter.delete(db, nil, SQL, params...)
	return
}

func (adapter *Postgres) DeleteWithTransaction(tx *sql.Tx, SQL string, params ...interface{}) (sc adapters.Scanner) {
	sc = adapter.delete(nil, tx, SQL, params...)
	return
}

func (adapter *Postgres) delete(db *sqlx.DB, tx *sql.Tx, SQL string, params ...interface{}) (sc adapters.Scanner) {
       ... implementation ...
}

[fabriziomello]

You don’t need break signatures. Maybe using some static variable to store sql.Tx should be enough to control if you’re inside a transaction or not. Em ter, 4 de set de 2018 às 17:46, Joel M. de Souza < notifications@github.com> escreveu:

@fabriziomello <https://github.com/fabriziomello> Example: func (adapter *Postgres) Delete(SQL string, params ...interface{}) (sc adapters.Scanner) { db, err := connection.Get() if err != nil { log.Println(err) sc = &scanner.PrestScanner{Error: err} return } sc = adapter.delete(db, nil, SQL, params...) return } func (adapter *Postgres) DeleteTx(tx *sql.Tx, SQL string, params ...interface{}) (sc adapters.Scanner) { sc = adapter.delete(nil, tx, SQL, params...) return } func (adapter *Postgres) delete(db *sqlx.DB, tx *sql.Tx, SQL string, params ...interface{}) (sc adapters.Scanner) { ... implementation ... } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlYgv9V5SGlLsDaKFi4hBJmx-uYvcnpks5uXuawgaJpZM4WT4FJ> .

-- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

[joelmdesouza]

Passing the transaction explicitly is more versatile and gives you more control because you have control over which transaction you are currently executing.
I do not like the idea of using a global transaction.
Using a local transaction makes the scope of actions better delimited.

What is the opinion of others on this issue?

[fabriziomello]

Create a method called SetTransaction then, or maintain a internal list of opened transactions. But seems we’re complicating things. My main concern is because in SQL we don’t have different DML for implicit or explicit transactions, we have just one Insert, Delete and Update. So seems natural we implement it in that way IMHO. Em ter, 4 de set de 2018 às 19:10, Joel M. de Souza < notifications@github.com> escreveu:

Passing the transaction explicitly is more versatile and gives you more control because you have control over which transaction you are currently executing. I do not like the idea of using a global transaction. Using a local transaction makes the scope of actions better delimited. What is the opinion of others on this issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#51 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlYghr-hL9B-U9j8dHTeEaT86Yxtf0cks5uXvpLgaJpZM4WT4FJ> .

-- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

[joelmdesouza]

I renamed the methods in the Postgres adapter and added the methods in the Mock adapter.

[felipeweb]

the code is fine, but I will document why I do not like this approach because we would have to create new endpoints for transaction actions.

What I would do is create 3 new endpoints open transaction that replies with UUID only for the transaction and another to commit and another to abort, if we pass? _TxID = "123" it would use the existing transaction otherwise it would continue as it is today

[joelmdesouza]

@felipeweb
Yes, I did not intend to expose a different endpoint to each transaction method.
This approach is only for the package level.
These methods I created would only be used in the commit endpoint.
The commit endpoint will execute all entries stored for that transaction, using InsertWithTransaction, DeleteWithTransaction.

tx, _ := adapter.GetTransaction()

    for (entries stored){
        adapter.InsertWithTransaction(tx, `Insert x ...`, ...)
        or
        adapter.DeleteWithTransaction(tx, `Delete x ...`, ...)
    }
tx.Commit()

[avelino]

Changed function signature, you need open PR (another repo) upgrading where you use the adapter

[joelmdesouza]

This function is only used inside the adapter package.
The other packages in the pRest project do not access it.