Migrate database to GORM and new schema #8
Conversation
jessegeens
force-pushed
the
fix/tx-sharing
branch
from
d79b75b to
a4e62e8
Compare
jessegeens
force-pushed
the
fix/tx-sharing
branch
from
a4e62e8 to
2cf6e37
Compare
jessegeens
force-pushed
the
fix/tx-sharing
branch
3 times, most recently
from
6b8c45a to
7843bfb
Compare
jessegeens
force-pushed
the
fix/tx-sharing
branch
2 times, most recently
from
f2d54aa to
48683cf
Compare
jessegeens
force-pushed
the
fix/tx-sharing
branch
from
48683cf to
ad9587a
Compare
jessegeens
force-pushed
the
fix/tx-sharing
branch
from
58d68e6 to
af4e08d
Compare
| UIDInitiator string | ||
| ItemType ItemType // file | folder | reference | symlink | ||
| InitialPath string | ||
| Inode string |
There was a problem hiding this comment.
Being a bit nitpicky, but since the fields are not ordered by name, I would at least order them by "function". I mean to have to kind of logic, like have inode close to instance, for example.
There was a problem hiding this comment.
You have a good point about the ordering. But in Go this actually also determines the memory layout, so this also determines the size of your struct. So let me see which order makes the most sense (although, since almost all fields are strings, I don't think it's going to matter much here)
There was a problem hiding this comment.
Reordering to something that makes more sense actually reduced the size :)
| Permissions uint8 | ||
| Instance string | ||
| Orphan bool | ||
| Description string |
There was a problem hiding this comment.
This prob makes sense for internal sharing. I would expect users to use the "name" as a kind of description of public links.
|
|
||
| type ShareState struct { | ||
| gorm.Model | ||
| ShareID uint `gorm:"foreignKey:ShareID;references:ID"` // Define the foreign key field |
There was a problem hiding this comment.
Do we need to define "shareid" givens that we already have a share, of type share, bellow? I would expect gorm to internally handle that.
There was a problem hiding this comment.
I tried this but you do need to explicitly have the foreign key field. And gorm then uses this to fill the actual Share child struct
| shareState = model.ShareState{ | ||
| Share: *share, | ||
| Hidden: false, | ||
| Synced: false, |
There was a problem hiding this comment.
Maybe sync should be true by default.. We don't use it now, but when we move the clients to reva, this might be used.. cc @glpatcern
| return nil, err | ||
| // Does not really matter if it fails, next time the user | ||
| // lists his shares this will just be called again | ||
| m.db.Save(&shareState) |
There was a problem hiding this comment.
Also, why are we persisting the defaults? I would argue this is adding unecessary rows to the DB. Also, functionally, we have a get function that does changes...
| func (m *mgr) appendUidOwnerFilters(ctx context.Context, query string, params []interface{}) (string, []interface{}, error) { | ||
| uidOwnersQuery, uidOwnersParams, err := m.uidOwnerFilters(ctx) | ||
| shareState, err := m.getShareState(ctx, &model.Share{ | ||
| ProtoShare: model.ProtoShare{ |
There was a problem hiding this comment.
You def need a getProtoShare... I really don't like all this repeated code.
| if m.isProjectAdminFromCtx(ctx, user) { | ||
| return "", []interface{}{}, nil | ||
| // Now we do the actual update to the db model | ||
| switch rs.State { |
There was a problem hiding this comment.
Why do we do this in 2 steps instead of doing it in the first switch? It's also because it's making me a bit confused that you can change both state and hidden fileds of a share, but then, the state overwrites the hidden value? Not sure I'm making sense...
|
As discussed via MM, I would also like to confirm that null values (via manually inserted rows) do not break anything. (or, we just set annotations with the proper sql configs). |
Following ADR-Reva-003, this PR refactors the sharing SQL logic to now use GORM, an ORM for Go. This change also comes with newly written unit tests for all the database logic.