Skip to content
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

Compound foreign key support #2

Open
michaelprichardson opened this issue Jul 10, 2020 · 3 comments
Open

Compound foreign key support #2

michaelprichardson opened this issue Jul 10, 2020 · 3 comments

Comments

@michaelprichardson
Copy link
Collaborator

The functionality to be able to string together multiple queries for the foreign key. At the moment there is only one .where(...). Being able to have multiple .where(...).where(...) (Note the firebase limits), would help the queries be more specific.

source: {
    collection: 'master/{someId}/detail',
},
targets: [
    {
        collection: 'details/{someId}/more_detail',
        foreignKey: 'masterId',
        where: [
            {
                field: 'masterId',
                operator: '==',
                value: someId
            },
            {
                field: 'secondId',
                operator: '>',
                value: 0
            },
        ]
    },
],
@nbransby
Copy link
Member

nbransby commented Jul 12, 2020

Could this not be simplified to

​source: {
    collection: 'users/{userId}/workingCopies',
},
targets: [
    {
        collection: 'changes',
        foreignKey:'workingCopy',
        where: {
           user: '$userId'
        }
    }
],

Do we have a use case for an operator other than ==?

@michaelprichardson
Copy link
Collaborator Author

I have not come across it yet where we need an operator other than ==. I thought about making it optional so that it can easily be changed if we need something else down the line.

So in the above example the where would be constructed as follows:

.where('workingCopy', '==', masterId) // As it has always been
.where('user', '==', userId) // New where

@nbransby
Copy link
Member

yep.

Might be worth compiling a list of all the relationship rules we need before implementing this so we know what functionality we will need

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants