Is it a good or a bad practice to have a Backbone model where its id is only unique among a collection but not unique globally? (because contextualized to that collection)
For instance I have a model A which contains bs a collection of model B.
The B collection belongs to the model A.
If I have a1 and a2 two instances of A, Can I use a B with id=1 in a1 and another B with id=1 in a2 ?
Maybe I don't see all the implication but it quite make sense, I just wanted to check with you before using it massively!
Thanks
If the 2 are separate collection you can definitely have id's that are unique to that collection.
Unless the 2 collections interact with each other which may cause any collision in ids
The question is that they represent the same entity or not...if yes their id can be the same otherwise I wouldnt recommend that. If they are the same entities they should be the same reference to a single object.
You will always have an autogenerated unique identifier for all Backbone models, the cid attribute.
Related
I'm creating a database schema with the following tables (sorry for the bad pseudocode):
User
====
user_id, PK
Collection
==========
collection_id, PK
user_id, FK(User->user_id)
Issue
=====
issue_id, PK
collection_id, FK(Collection->collection_id)
There is a one-to-many relationship from User to Collection, and also from Collection to Issue. So, a single user may maintain multiple collections, each with many issues.
The problem: I would like to designate a "default" collection to be displayed when the user first logs in to the application. For the record, I'm doing this in the Django framework, but I'm more interested in the elegant platform-independent solution. When I try to make a column in User that is a Foreign Key to Collection, it complains that Collection does not exist yet (I suppose because User is created first). I could add a "default" boolean column to Collection and enforce through my application that only one record per User be "true", but that seems inelegant. I could also have a separate table, say, User_Default_Collection, which has user_id as a Foreign, Unique Key, and a collection_id column which is a Foreign Key to Collection. But I'm certain this is also less than 3rd normal form. Any suggestions?
If you want to enforce that every user must and will always have his "default" collection, then because of the obvious cycle in the inclusion dependencies you are forced into either deferred constraint checking (if your DBMS allows the FK cycle to be declared in the first place) or application-enforced integrity.
If you can tolerate users not having any default collection at all, then create a separate table DFT_COLL(userid, dft_coll_id) with key userid and FK's to both USER and COLLECTION.
If it gives you trouble in cases when a user has no default collection, maybe this can still be addressed by having the system just pick one (e.g. the one with the lowest [or highest] id) and implement this with a UNION view (so that if you need the default then you read the UNION view and you're guaranteed (*) to get some result).
(*) If the user has a collection at all, that is. Note that requiring a default collection and requiring that to exist, implies requiring at least one collection per user. (And the corollary of this is that if it must be allowed for a user to have no collection at all, it is nonsensical and a contradiction to require him to have a default one.)
The most plausible solution i think would be:
Add nullable "default" field to Collection table
Create UNIQUE constraint for used_id and default
Keep "true"-s and NULLs (no false's) in "default" column.
This will not allow for multiple Collections associated with the same user_id to have the same "default" value other than null. You don't need to develop any application logic. However, this design would not force you to always have a default collection for a user.
Here's a brief description of the models:
Model A represents a piece of equipment and has a name and a state
Model B represents a specific state of many model A's
Model B should relate to many model A's but only for a specific state of model A
Is it possible to model something like this in the datastore? I need the state of model A to be independent of any model B's, but when I peer into a model B I need to know what the state of the model A's should be that the model B is representing.
The current way I am achieving this is by making model B have string fields representing the different model A's with the name of the field being the name of the model A and the value of the field being the state the model A is supposed to be in.
This works, however it's completely static and requires manually adding fields into model B when the number of model A's change. I'm looking for a dynamic approach to solve this problem.
I hope this isn't too confusing, please ask for more clarification if it's needed.
You can use reference properties for this:
class A(db.Model):
state = db.ReferenceProperty(collection_name="equipment")
When you create A, you set the state property to the corresponding B entity.
This also creates a property in the B entity called equipment that can be used to get all the A entities that reference the particular B.
Suppose you have a B entity for broken equipment in a variable broken. You can get all the broken equipment this way
broken.equipment.get()
This is also available with ndb but the details are a little different and you'll need to check the docs for that.
Say I have done a query and I want to then order it by a reference property attribute - can I temporarily add a field in the results of my query and add in the attribute to sort it before I send it to the template?
q = LetterTable.all().order('votes)
but then I want to take the q results above and sort on a property of LetterTable called "Person". However, 'person' is a reference to an instance on the PersonTable, so I don't want the reference object, I want to sort by person.name. How can I do this?
Anyone?
You can't, at least not stright out of the box. There's some page in the GAE docs that describe how queries work. Essentially your entities are indexed by property, and when you run a query, it just looks through the index.
In your case, the index contains the reference property and not the PersonTable entity it refers to, so the index doesn't have person.name.
The appropriate way to do this in App Engine is to denormalize. That means storing an extra copy of some data you need, in this case, you'd store a copy of person.name inside your LetterTable entity. Then you can query and sort on that name.
class LetterTable(db.Model):
person = db.ReferenceProperty(Person)
person_name = db.StringProperty()
This method certainly has its drawbacks, the primary being keeping data in sync (ie, if a person changes their name, you'll have to find all LetterTable instances that refer to that person, and change all the denormalized names).
In my model i've defined relationship, so it's property with foreign key is substituded by related model.
I had an idea to give away from database two same values, for example relatedId and related - if i define models relationships for field related, relatedId value will be left untouched - and i will be able to use it.
Is it possible somehow to use collection.where() method in backbone relational on model attributes, that represent related models (they have object data type)? if i define related id - like following - it does not work:
collection.where({
related : 14 // this property contains related model, but not id after backbone initializes, i've also tried to use relatedId key instead - this does not work
})
I need such method very much, because i have to find models by lot of attributes, and it is very hard to do it from scratch :/
Could you please advice a way?
I really like using database "views" to effectively flatten relationships for way easier querying. It works well.
I'm trying to wrap my head around how I can represent a many-to-many relationship inside of AppEngine's Datastore in the Go Programming Language. I'm more used to traditional relational databases.
I have two types of entities in my system. Let's call them A and B. Every A entity is related to some number of B entities. Similarly, every B entity is related to some other number of A entities. I'd like to be able to efficiently query for all B entities given an A entity, and for all A entities given a Bentity.
In the Python SDK, there seems to be a way to note fields in an entity can be ReferencePropertys which reference some other entity. However, I can't find something similar in Go's AppEngine SDK. Go seems to just use basic structs to represent entities.
What's the best practice for dealing with this?
A python ReferenceProperty essentially stores a key to another entity. It's similar to using a Key field in Go.
There's at least two ways to solve your problem. A cheap way to store a limited number of references, and an expensive way for larger data sets.
fmt.Println.MKO provided the answer for the cheap way, except the query is simpler than what he suggests, it should actually be:
SELECT * FROM B where AIds = 'A1'
This method is limited to the number of indexed entries per entity, as well as the entity size. So the list of AIds or BIds will limit the number of entities to 20000 or less.
If you have an insane amount of data, you would want a mapping entity to represent the M2M relationship between a given A & B entity. It would simply contain a key to an A and a key to a B. You would then query for map entities, and then fetch the corresponding A or B entities you need. This would be much more expensive, but breaks past the entity size limit.
based on how you which to query you could do the following:
in your struct A add a field:
BIds []int64
in your struct B add a field:
AIds []int64
now any time you add a relation between A and B you just need to add the corresponding ids to your two variables
when you need to query now for all B which are related to this A1 you do your query like this:
SELECT * FROM B where AIds = 'A1'
for all A wich are related to this B1 your do it similar:
SELECT * FROM A where BIds = 'B1'
update:
altered querys on suggestion from dragonx