I am currently using Cognito and Django together. I also have a rds postgres instance as my db.
I am curious what are the pros and cons of using CognitoId as my User's primary key
versus having unique uuid4 primary key for my user and a cognito_id field.
class User(AbstractUser):
user_id = models.UUIDField(primary_key=True, default=uuid4)
cognito_id = models.UUIDField(default=uuid.uuid4, editable=False)
OR
class User(AbstractUser):
cognito_id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
Are there any reasons the second version that uses cognitoID would run into issues?
For your use case there is no issue. You can use sub Id as the primary key in your database, it is globally unique. Only if you plan to use this database to restore users, you won't be able to restore the sub id. It will generate a new one. But I don't think that is part of your use case anyway.
Related
Just starting with Domain Driven Design and I've learned that you should keep your model in a valid state and when creating a new instance of a class it's recomended to put all required attributes as constructor parameters.
But, when working with auto incremented keys I just have this new ID when I call an Add method from my persistent layer. If I instanciate my objects without a key, I think they will be in a invalid state because they need some sort of unique identifier.
How should I implement my architecture in order to have my IDs before creating a new instance of my entity ?
Generated Random IDs
The pragmatic approach here is to use random IDs and generate them before instantiating an entity, e.g. in a factory. GUIDs are a common choice.
And before you ask: No, you won't run out of GUIDs :-)
Sequential IDs with ID reservation
If you must use a sequential ID for some reason, then you still have options:
Query a sequence on the DB to get the next ID. This depends on your DB product, Oracle for example has them).
Create a table with an auto-increment key that you use only as key reservation table. To get an ID, insert a row into that table - the generated key is now reserved for you, so you can use it as ID for the entity.
Note that both approaches for sequential IDs require a DB round-trip before you even start creating the entity. This is why the random IDs are usually simpler. So if you can, use random IDs.
DB-generated IDs
Another possibility is to just live with the fact that you don't have the ID at creation time, but only when the insert operation on the DB succeeds. In my experience, this makes entity creation awkward to use, so I avoid it. But for very simple cases, it may be a valid approach.
IN adition to theDmi's comments
1) You can in your factory method make sure your entity gets stored to the database. This might or might not be applicable to your domain but if you are sure that entity is going to be saved that might be a valid approach
2) You can separate the ID from the primary key from the database. I've worked with a case there something was only an order if the customer payed and at that point it would be identified by it's invoice id (a sequentual ID). that doesn't mean in the database i would need an column ID which was also the primary key of the object. You could have a primary key in the database (random guid) and till have an ID (int?) to be sequentual and null if it hasn't be filled yet.
Im trying to migrate our current application over to Laravel-5.
This app has quite a big structure with many tables, but way less than half of the tables has a primary key called id.
Is this a problem or can you manualy specify what you want your primary key to be called.
Its just that from the training videos I am doing, it seems like no.
You can use
protected $primaryKey = 'Your_Primary_key';
In the Models.
Sure, just add $table->primary('field') to your database shema as mentioned here: http://laravel.com/docs/5.0/schema#adding-indexes
$table->string('your_primary_key', 32)->primary();
'your_primary_key' is the name's primary key
32 is length
I try and it work
http://laravel.com/docs/4.2/eloquent#relationships
what does local key mean in this thing? does it mean primary key of the table? or what? for example in this code
return $this->hasOne('Phone', 'foreign_key');
return $this->hasOne('Phone', 'foreign_key', 'local_key');
local_key is the primary key of your table. You only need to specify it if your primary key is not called id AND you do not have the $primaryKey property set in your model.
I believe everything is written in the doc:
ake note that Eloquent assumes the foreign key of the relationship based on the model name. In this case, Phone model is assumed to use a user_id foreign key. If you wish to override this convention, you may pass a second argument to the hasOne method. Furthermore, you may pass a third argument to the method to specify which local column that should be used for the association:
Which basically means that 'local_key' is the name of the table column in your db which is responsible to match the related entity (phone) with your current entity (user).
If you have a look at the db, I'm sure you'll find a table user with a phone_id column, try to change it to something else (like "phone" only) and your eloquent request will crash. Then change your call to return $this->hasOne('Phone', 'user_id', 'phone'); and this might work again.
I have a User table with the following details in my android DB
username, password, email, mobile,
I have another table named Service with the following detail in my android DB
service name, service category, service description
Now, I want to associate the relationship for every user (eg: username) with his/her service (service name) using ORMLite.
I want to maintain a seperate table for this relationship. Now, my question goes like this
Is is possible for ORM that it generates a table if I specify the primary key and foreign key relation, such that it can populate the data for every service getting added ?
Do I have to create a bean maintaining the common fields between my user table and service table and do the insertion task manually whenever a new service is added ?
-Thanks
Srikant
Looks like you may have solved you own problem but I'll still answer for posterity. ORMLite calls this relationship between User and Service a "foreign object" fields. Here's the documentation for foreign objects. It sounds like User is associated with a service so your User class would have a Service service; field. Something like:
public class User {
...
#DatabaseField(canBeNull = false, foreign = true)
private Service service;
}
Now your questions:
Is is possible for ORM that it generates a table if I specify the primary key and foreign key relation, such that it can populate the data for every service getting added ?
ORMLite does not handle foreign key limitations although you can tune the schema yourself to add it. If you setup the foreign key then it will use the primary key from Service in your User table.
Do I have to create a bean maintaining the common fields between my user table and service table and do the insertion task manually whenever a new service is added ?
Not sure I understand the question. All you need to do is create your Service using the serviceDao and then add the server to your User before creating it using the userDao.
I am trying to create a mapping to a database table that has no primary keys/references.
public class TestMap : ClassMap<<Test>Test> {
public TestMap() {
WithTable("TestTable");
Map(x => x.TestColumn);
}
}
This fails and expects id or composite-id. Is this possible in fluent nhibernate?
In Oracle at least, I have used "ROWID" for this. For mssql you might use the "ROW_NUMBER()" builtin function for readonly access to the table, but I haven't tried that...
No. You'll have to add a surrogate primary key, such as an identity column in SQL Server, to map this table. As far as I know, this isn't supported by NHibernate itself.
Why don't you have a primary key on this table?
This functionality isn't supported by nhibernate as far as I know. As a general rule of thumb, however, you should really always have some kind of ID and if you find yourself in a situation where you think you don't need one you should assess your data model. An ID, whether it be a table-specific primary key, or a surrogate key from another table, should exist. This not only ensures that nhibernate can process the table, but helps performance via indexing.
Before you start assuming nhibernate isn't going to fulfill your needs, consider why you don't have a key on the table and what kind of sense it makes not to have one.
If we can bring a column from table having no primary key/identity coulmn, then we can use fluent as below:
Id(x => x.TempID).Column("TempID");
If the table contains data that belongs to another entity, you could map it as a collection of components. Components are not identified by themselves, but they belong to another entity, which is identified.
You can map an entity to a table without keys defined in the database. I do so in legacy SQL Server databases. However, the table must have a candidate key (some set of columns that actually stores a unique combination of values). The concept of entity involves the notion of some kind of identity.
Instead of this, what you're trying in your code is to map an entity without identity, wich isn't possible.