I don't see anyone asking this question or it being in documentation, but what are the differences between defining a user store as primary or secondary and what advantage does one have over another?
For the users in primary userstore, you can simply use their username. (eg. userX) But, for the users in secondary userstores, you have to use domain/username to identify them. (eg. domainX/userY)
When you have multiple userstores, you can have only 1 primary one, and rest should be secondary. There are no advantages or disadvantages as such.
If you don't have multiple userstores, you can simply go with the primary one.
Related
Why does the TYPO3 Extension Builder don't generate Foreign keys?
I've set some relations between the models, but in SQL Code there are noe FKs only colums for the Value of the key.
Does anyone can help me?
Cite from Kartsen Dambekalns
It is a half-conscious design decision. Just look up the date when
foreign key constraints where introduced in MySQL, and compare to when
TYPO3 was 'born'.
Of course it would be great to add such references, especially since
MySQL can always handle themm, even if the underlying storage engine
doesn't handle them (in case of which they'll just be ignored).
(source)
Nothing changed till now, so you need to create foreign keys yourself after modeling.
Answer to comment:
how did you handle the relations between two tables? for example I've got a table people which relates to the table house with the column housenr
That depends on relation type of course (1:n, n:1, m:n, etc) and Builder supports creating relations in modeling tool perfectly. Keep in mind, that foreign keys are NOT required for keeping relations in TYPO3.
There are some rules described in TCA section of documentation, i.e. in mentioned case you can use select or group (with internal_type) type of field. For many-to-many relation also you'll need to create MM table. If you'll follow these documents, you can be sure, that in common backend editing form they will be handled properly.
As mentioned before Extension Builder supports creating different types of relations in its click-click modeling tool and it's worthy to spend some time to play with it to see how relations of different types are handled in TYPO3. It uses the same rules that are used in creating relations also in pre-extbase extensions. What's more Builder adds required methods to the models i.e. for getting, attaching and detaching MM objects of given relation field, therefore it's most important to model all your relations at start. In other case you'll need to write these methods manually (which is boring process)
Consider that in the database you have a table called users and a table called wallets. Among other things a user has 0, 1 or more wallets. The relation is one to many, meaning that the wallet has a foreign key pointing at the user.
Now the question is the following: When building a struct or a class for a person I see two possibilities:
1) The user has no sign of wallet. There is a function which takes a user as arguments and will fetch an array of the wallets.
2) The user has as a member which is an array containing the wallets and the wallets are fetched when the object / struct is created.
I think that the first approach may be better, since it's more modular - in the second one the users depend on the wallets, even if the user has no wallets.
Still, I am not sure which approach is better so I am looking for a comparison of both approaches.
On the application level you might have a user type like this (Go notation):
type User interface {
Wallets() []Wallet
}
Far beneath, there's a database which in your case is SQL. That should not be obvious by looking at your application, thought.
Making assumptions about dependencies beyond what they guarantee in the form of interface contracts couples the components irreversibly.
That means that if you model your application by your database's schema you're doing it wrong because your entire application is now tightly coupled to said database and any change to any part of it will have a big, unpredictable impact.
A common solution is to use a so called ORM layer, which sits between your database driver and entity models. It will take care of stuff like:
how and when should the wallets be fetched?
where in the database is a wallet's information stored?
when you remove a user, should the wallet also be deleted?
among other things.
PS: This answer applies to both, statically and dynamically typed languages.
Can someone explain the significance of specifying a relationship in a Django model as one-to-one as opposed to just a foreign key?
Specifically, I'm wondering what advantages you get from specifying a relationship as 1-1, if any.
Thanks so much.
The OneToOneField evolved in Django after 'ForeignKey'. Conceptually a ForeignKey with unique=True constraint is similar to OneToOneField.
So if you want to ensure that every picture has one user and vice-versa use a OneToOneField.
If you want one user to have any number of pictures use a ForeignKey.
The way things are selected are also different. In case of doing OneToOneField, you can do user.picture and get the picture directly. In case of ForeignKey you will do user.picture_set[0] to get the first picture or access all the pictures associated with that user.
MultiTableInheritance implicitly uses OneToOneField internally and you can see where the concept originated from.
The additional constraints of a 1-1 provide a tighter and richer conceptual model but can also provide insight that can allow for more intuitive retrieval. As a many to one represents a parent/collection relationship there is an unclear cost associated with the retrieval of any given collection for a particular entity. Since a 1-1 provides a flat mapping there is also a flat cost of retrieval. This would lead to things like preferring eager fetching when relevant, as the join will be be able to be easily optimized and the resultant data set will be a known size.
They are not the same; think about it:
If you have a one-to-one relationship between a User and a Picture, you are saying that a user can only have one picture (and a picture can only have one user). If you were to have a Picture with foreign key to User, then you are saying that a picture must have exactly one user, but a user may have 0, 1 or many pictures.
Django's Foreign Key is a many to one relationship. Now, the difference between them is the same as the difference between a One-To-One and Many-To-One relationship. For example, if you have User and Profile entities. You would like to add a constraint that each User could have one and only one Profile. Then, using a django's one to one field would create a restriction on the database level so, that you won't be able to relate User to multiple Profiles or vice-versa. Where as using Foreign Key wouldn't provide this constraint.
I'm building a web app on Django. The client insists that some column on some table should be the primary key, he doesn't want autoincrement one. But also he wants that column to be modifiable in application, pointing that Postgres can deal with it (ON UPDATE CASCADE clause). How can I lead him out of it, or maybe I should agree to that? He's stubborn.
Edit:
I want to know at least whether doing things as he says is harmful, or what are some gotchas in this approach.
It can be done, from Django's docs regarding auto pk:
If you'd like to specify a custom primary key, just specify
primary_key=True on one of your fields. If Django sees you've
explicitly set Field.primary_key, it won't add the automatic id
column.
However, pk's are usually used for object identity and retrieval. Managing them manually and ensuring uniqueness is a PITA, it's not just editing them, the also need to present and unique when the object is created and stored in the db for example.
Instead of deleting records in my Django application, I want to just mark them as "deleted" and have them hidden from my active queries. My main reason to do this is to give the user an undelete option in case they accidentally delete a record (these records may also be needed for certain backend audit tracking.)
There are a lot of foreign key relationships, so when I mark a record as deleted I'd have to "Cascade" this delete flag to those records as well. What tools, existing projects, or methods should I use to do this?
Warning: this is an old answer and it seems that the documentation is recommending not to do that now: https://docs.djangoproject.com/en/dev/topics/db/managers/#don-t-filter-away-any-results-in-this-type-of-manager-subclass
Django offers out of the box the exact mechanism you are looking for.
You can change the manager that is used for access through related objects. If you new custom manager filters the object on a boolean field, the object flagged inactive won't show up in your requests.
See here for more details :
http://docs.djangoproject.com/en/dev/topics/db/managers/#using-managers-for-related-object-access
Nice question, I've been wondering how to efficiently do this myself.
I am not sure if this will do the trick, but django-reversion seems to do what you want, although you probably want to examine to see how it achieves this goal, as there are some inefficient ways to do it.
Another thought would be to have the dreaded boolean flag on your Models and then creating a custom manager that automatically adds the filter in, although this wouldn't work for searches across different Models. Yet another solution suggested here is to have duplicate models of everything, which seems like overkill, but may work for you. The comments there also discuss different options.
I will add that for the most part I don't consider any of these solutions worth the hassle; I usually just suck it up and filter my searches on the boolean flag. It avoids many issues that can come up if you try to get too clever. It is a pain and not very DRY, of course. A reasonable solution would be a mixture of the Custom manager while being aware of its limitations if you try searching a related model through it.
I think using a boolean 'is_active' flag is fine - you don't need to cascade the flag to related entries at the db level, you just need to keep referring to the status of the parent. This is what happens with contrib.auth's User model, remember - marking a user as not is_active doesn't prompt django to go through related models and magically try to deactivate records, rather you just keep checking the is_active attribute of the user corresponding to the related item.
For instance if each user has many bookmarks, and you don't want an inactive user's bookmarks to be visible, just ensure that bookmark.user.is_active is true. There's unlikely to be a need for an is_active flag on the bookmark itself.
Here's a quick blog tutorial from Greg Allard from a couple of years ago, but I implemented it using Django 1.3 and it was great. I added methods to my objects named soft_delete, undelete, and hard_delete, which set self.deleted=True, self.deleted=False, and returned self.delete(), respectively.
A Django Model Manager for Soft Deleting Records and How to Customize the Django Admin
There are several packages which provide this functionality: https://www.djangopackages.com/grids/g/deletion/
I'm developing one https://github.com/meteozond/django-permanent/
It replaces default Manager and QuerySet delete methods to bring in logical deletion.
It completely shadows default Django delete methods with one exception - marks models which are inherited from PermanentModel instead of deletion, even if their deletion caused by relation.