-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement many to many relationships #183
base: feature/m2m
Are you sure you want to change the base?
Conversation
test generation on appveyor
remove empty lines at the start and the end of a block
Signed-off-by: Miguel Molina <[email protected]>
allow definition of primary keys directly on kallax.Model tags
fix readme
src-d#188 readme fix
a9e84f6
to
c2349a3
Compare
Signed-off-by: Miguel Molina <[email protected]>
generate N:M foreign keys on schema
Signed-off-by: Miguel Molina <[email protected]>
generate With methods for N:M relationships
Codecov Report
@@ Coverage Diff @@
## feature/m2m #183 +/- ##
===============================================
+ Coverage 78.94% 79.35% +0.41%
===============================================
Files 19 19
Lines 3590 3798 +208
===============================================
+ Hits 2834 3014 +180
- Misses 544 560 +16
- Partials 212 224 +12
Continue to review full report at Codecov.
|
Signed-off-by: Miguel Molina <[email protected]>
There is a problem with the automatic insert+update of relationships with a table in between: it's a record that may need to be initialized in some way (imagine a database that used For example, imagine the following scenario: type User struct {
kallax.Model
ID uuid.UUID
}
type Post struct {
kallax.Model
ID uuid.UUID
}
type UserPost struct {
kallax.Model
ID uuid.UUID
User *User
Post *Post
} In this case, the user will need to set the ID in the constructor, and this is necessary before inserting this record in the database. The problem there is that constructors can have arbitrary parameters and we're not magicians so we don't know how to call them behind the scenes. There's only so much magic we can do. So, we can either think of a solution for this that is nice for the user (which I can't really think of right now) or one the following:
Note that updates are not a problem, since they don't need the Any thoughts? |
I'm adding this to backlog, to keep track in the future. |
In the upcoming days, I'm merging this into a wip/feature branch in order to work more confortably from it. Please, consider discussing any issues on the open issue related to this (#114). After merging this PR, destination branch will be rebased to master (I'm praying to the flying spaguetti monster, cthulu, or whoever can help me) and another PR will be created when the feature is complete (or, at least, usable) in case someone wants to review it. |
Sooo... what's the status? Are you guys gone full go-mysql-server or what? |
@iorlas Thanks for your interest. I cannot speak for src-d, but personally I lack the time needed to push this feature forward. |
This PR is the first of several that will be merged into
feature/m2m
, which will be merged when full support for many to many relationships is completely finished.What is introduced in this PR?
through
struct tag of a field via methods ofField
type.batchRunner
for retrieving N:M relationships. 1:N using a through should work but that is yet to be tested.Notable changes and breaking changes
Identifier
now has anewPtr
method used to get a new fresh empty pointer of that identifier type (internal, just used in the batcher). This restricts the extension of theIdentifier
interface, though, which is probably not a big deal.Scan
now accepts N extra pointers. Again, it's internal and not really exposed to the public, so we should be good.ManyToMany
has been renamed toThrough
, as 1:N with an intermediate table also need to be processed as aThrough
kind of relationship.ForeignKeys
has now a slice of foreign keys, instead of just one. Only generated code uses it, but it will be broken until regeneration.What's left?
At least, all the internal mumbo jumbo should be done with this PR.
Review
I suggest you take a look at it per-commit, as they are very clear and separate functionalities. (Should have made 2 PRs actually, but /shrug)
CI
Yes, CI is failing and will be until code generation is implemented, because of the
ForeignKeys
internal breaking change.