FAQ
With flat data models the associated data of a single object may reside
across a wide 'geography' of Firebase locations. An example of this, in
our case, is the 'User' and his/her primary 'Account'. Primary, in that a
user may also have access to multiple Accounts - further exacerbating the
potential distance across his/her fb locations.

For example.

Account: 'ABC', has associated 'Contacts, 'Assets', 'Locations', in
addition to 'Account Members', and an 'Account Owner'. Current structure
is similar to the following;

accounts": {
     "accountId": {
       "id": "firebase_id",
       "name": "",
               "accountOwner": userId
       "locations": {
         "locationId": true
       },
       "owner": {
         "userId": true
       },
       "members": {
         "userId": true
       },
       "contacts": {
         "listId": true
       },
       "assets": {
         "assetlistId": true
       }
     }
   },
"account_members": {
     "accountId": {
       "userId": true
     }
   },
"locations": {
     "accountId": {
       "location1": {
           "location-details": detail
        },
        "location2": {
            "location-details": detail
        }
     }
},
"contacts": {
     "accountId": {
       "contact1": {
           "contact-details": detail
        }
     }
},
"assets": {
     "accountId": {
       "asset1": {
           "asset-details": detail
        }
     }
},
"users": {
     "userId": {
       "accounts": {
           "accountId": true
        }
     }
}


First question. Does this appear to be best model? We have others that
actually include each item across objects -- so all contactIds would also
be located under accounts as well i.e.
accounts/:accountId/contacts/contactId: true

But in many cases it simply doesn't seem necessary, nor more efficient that
we can tell.

Second question is centered on extending both the User, and Account models
to include methods that provide each associated location as $.asArray();

Example:
Extended Account Object 'snip'

var relatedAssets = ['locations', 'members', 'assets', 'contacts' ];

angular.forEach ( relatedAssets, function ( asset ) {
   var exist = exists ( asset ); // hasOwnProperty lookup to check and see
if the reference exists on the object
   if ( exist ) {
     var name = rename ( asset );
     account[name] = fB.asArray ( asset, account.$id );
     watch ( name, asset ); // also set $watch on the associated to update
the object indexList in those instances where having the $id:true structure
is beneficial
   }
} );

We then extend the User object to call the $extendedObject of the Account,
so the User object (cough) 'inherits' the associated Account methods, in
addition to its own.

Is this
A) good idea? bad idea?
B) is there a better way?
C) intended use of the $.extendedObject/Array

Thanks.





--
You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
To post to this group, send email to firebase-angular@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/600c5ee6-a5e8-4000-aee1-c7bff48838bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Kato Richardson at Mar 9, 2015 at 10:25 pm
    Hello Bo,

    This is a common approach. I've used a similar technique
    <http://jsfiddle.net/katowulf/vspo65qm/> myself in a few examples. In some
    naïve use cases, you can just merge the data in the UI
    <http://jsfiddle.net/katowulf/uoe5yt8x/> as well.

    Cheers,
    Kato

    On Sat, Mar 7, 2015 at 11:15 PM, Bo Coughlin wrote:

    With flat data models the associated data of a single object may reside
    across a wide 'geography' of Firebase locations. An example of this, in
    our case, is the 'User' and his/her primary 'Account'. Primary, in that a
    user may also have access to multiple Accounts - further exacerbating the
    potential distance across his/her fb locations.

    For example.

    Account: 'ABC', has associated 'Contacts, 'Assets', 'Locations', in
    addition to 'Account Members', and an 'Account Owner'. Current structure
    is similar to the following;

    accounts": {
    "accountId": {
    "id": "firebase_id",
    "name": "",
    "accountOwner": userId
    "locations": {
    "locationId": true
    },
    "owner": {
    "userId": true
    },
    "members": {
    "userId": true
    },
    "contacts": {
    "listId": true
    },
    "assets": {
    "assetlistId": true
    }
    }
    },
    "account_members": {
    "accountId": {
    "userId": true
    }
    },
    "locations": {
    "accountId": {
    "location1": {
    "location-details": detail
    },
    "location2": {
    "location-details": detail
    }
    }
    },
    "contacts": {
    "accountId": {
    "contact1": {
    "contact-details": detail
    }
    }
    },
    "assets": {
    "accountId": {
    "asset1": {
    "asset-details": detail
    }
    }
    },
    "users": {
    "userId": {
    "accounts": {
    "accountId": true
    }
    }
    }


    First question. Does this appear to be best model? We have others that
    actually include each item across objects -- so all contactIds would also
    be located under accounts as well i.e.
    accounts/:accountId/contacts/contactId: true

    But in many cases it simply doesn't seem necessary, nor more efficient
    that we can tell.

    Second question is centered on extending both the User, and Account models
    to include methods that provide each associated location as $.asArray();

    Example:
    Extended Account Object 'snip'

    var relatedAssets = ['locations', 'members', 'assets', 'contacts' ];

    angular.forEach ( relatedAssets, function ( asset ) {
    var exist = exists ( asset ); // hasOwnProperty lookup to check and see
    if the reference exists on the object
    if ( exist ) {
    var name = rename ( asset );
    account[name] = fB.asArray ( asset, account.$id );
    watch ( name, asset ); // also set $watch on the associated to update
    the object indexList in those instances where having the $id:true structure
    is beneficial
    }
    } );

    We then extend the User object to call the $extendedObject of the Account,
    so the User object (cough) 'inherits' the associated Account methods, in
    addition to its own.

    Is this
    A) good idea? bad idea?
    B) is there a better way?
    C) intended use of the $.extendedObject/Array

    Thanks.





    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/600c5ee6-a5e8-4000-aee1-c7bff48838bd%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/600c5ee6-a5e8-4000-aee1-c7bff48838bd%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/CADypTEYXY-8j%3DCnvrEhqNavi1LujALcpaJuZ3ypWU%2B8%3Dfeurzw%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bo Coughlin at Mar 14, 2015 at 3:42 am
    Much thanks Kato, you continue to be both scholar and gentleman. - bo
    On Monday, March 9, 2015 at 6:25:39 PM UTC-4, Michael Kato Wulf wrote:

    Hello Bo,

    This is a common approach. I've used a similar technique
    <http://jsfiddle.net/katowulf/vspo65qm/> myself in a few examples. In
    some naïve use cases, you can just merge the data in the UI
    <http://jsfiddle.net/katowulf/uoe5yt8x/> as well.

    Cheers,
    Kato


    On Sat, Mar 7, 2015 at 11:15 PM, Bo Coughlin <b...@kikstand.com
    <javascript:>> wrote:
    With flat data models the associated data of a single object may reside
    across a wide 'geography' of Firebase locations. An example of this, in
    our case, is the 'User' and his/her primary 'Account'. Primary, in that a
    user may also have access to multiple Accounts - further exacerbating the
    potential distance across his/her fb locations.

    For example.

    Account: 'ABC', has associated 'Contacts, 'Assets', 'Locations', in
    addition to 'Account Members', and an 'Account Owner'. Current structure
    is similar to the following;

    accounts": {
    "accountId": {
    "id": "firebase_id",
    "name": "",
    "accountOwner": userId
    "locations": {
    "locationId": true
    },
    "owner": {
    "userId": true
    },
    "members": {
    "userId": true
    },
    "contacts": {
    "listId": true
    },
    "assets": {
    "assetlistId": true
    }
    }
    },
    "account_members": {
    "accountId": {
    "userId": true
    }
    },
    "locations": {
    "accountId": {
    "location1": {
    "location-details": detail
    },
    "location2": {
    "location-details": detail
    }
    }
    },
    "contacts": {
    "accountId": {
    "contact1": {
    "contact-details": detail
    }
    }
    },
    "assets": {
    "accountId": {
    "asset1": {
    "asset-details": detail
    }
    }
    },
    "users": {
    "userId": {
    "accounts": {
    "accountId": true
    }
    }
    }


    First question. Does this appear to be best model? We have others that
    actually include each item across objects -- so all contactIds would also
    be located under accounts as well i.e.
    accounts/:accountId/contacts/contactId: true

    But in many cases it simply doesn't seem necessary, nor more efficient
    that we can tell.

    Second question is centered on extending both the User, and Account
    models to include methods that provide each associated location as
    $.asArray();

    Example:
    Extended Account Object 'snip'

    var relatedAssets = ['locations', 'members', 'assets', 'contacts' ];

    angular.forEach ( relatedAssets, function ( asset ) {
    var exist = exists ( asset ); // hasOwnProperty lookup to check and
    see if the reference exists on the object
    if ( exist ) {
    var name = rename ( asset );
    account[name] = fB.asArray ( asset, account.$id );
    watch ( name, asset ); // also set $watch on the associated to
    update the object indexList in those instances where having the $id:true
    structure is beneficial
    }
    } );

    We then extend the User object to call the $extendedObject of the
    Account, so the User object (cough) 'inherits' the associated Account
    methods, in addition to its own.

    Is this
    A) good idea? bad idea?
    B) is there a better way?
    C) intended use of the $.extendedObject/Array

    Thanks.





    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angul...@googlegroups.com <javascript:>.
    To post to this group, send email to firebase...@googlegroups.com
    <javascript:>.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/600c5ee6-a5e8-4000-aee1-c7bff48838bd%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/600c5ee6-a5e8-4000-aee1-c7bff48838bd%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/96494a4a-7ea8-415b-abad-f8a0b565bdaa%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupfirebase-angular @
postedMar 8, '15 at 6:15a
activeMar 14, '15 at 3:42a
posts3
users2

2 users in discussion

Bo Coughlin: 2 posts Kato Richardson: 1 post

People

Translate

site design / logo © 2021 Grokbase