3

Should a DAO save() method set the id/pk of the instance that is to be saved and return the instance or should it just return the PK?

// Example A: Return the instance
studentDAO = {
  save: function(student) {
    const id = db.query('INSERT INTO `students`...');
    student.setId(id);

    return student;
  }
}

// Example B: return the save id and it's up to me to set it 
// outside of the DAO
studentDAO = {
  save: function() {
    const id = db.query('INSERT INTO `students`...');

    return id;
  }
}

And usage of the above:

// Example A
student = new Student();
student = studentDao.save(student);

// Example B
student = new Student();
idStudent = studentDao.save(student);
student.setId(idStudent);
4

This bit is wrong:

    const id = db.query('INSERT INTO `students`...');

student.Id should already be set when the save function is called. The db should use that supplied Id. There should be no new Id to return.

eg.

public class Student
{
    public string Id {get;set;}
    public Student()
    {
        this.Id = Guid.NewGuid().ToString();
    }
}

Depending on knowledge of all students to be able to create a single new student adds a choke point to any system and will cause no end of issues.

  • Wait what? Isn't the database that decides such unique id's, based on auto-increment mechanisms? – Nik Kyriakides Jul 13 '17 at 17:14
  • no, that would be crazy. you would have to save before you knew the id! how would you create a list of them. I spz you could do a complicated reserving integers system – Ewan Jul 13 '17 at 17:15
  • ok i am being slight sarcastic, but this argument has been gone over a bazillion times. There are many advantages to not using database generated ids and this is one. – Ewan Jul 13 '17 at 17:20
  • 1
    @Ewan allowing Student to self-assign an id in the constructor. May not lead to unexpected behaivors? For instance, missing when the id really exist in the db or when It just exists in memory? Is not the DAO who assign the ID and then saves the instance? So if it fails, set the id to null too? – Laiv Jul 13 '17 at 17:32
  • 1
    No. the constructor ensures that all Student instances on any machine before and after saving have a unique id. If you have a business rule which says that students should not have an "id" until they are persisted in the DB then a: that should be questioned. and b: really we are talking about some sort of registration number that we call an "id" not the Id of a Student object in the computer system, which needs an Id for each student even if then don't complete the online form or whatever – Ewan Jul 13 '17 at 17:33
0

The database is either going to use a 'natural' key or 'artifical' one. The primary key is important and it should be returned by the insert (DAO) if the database is generating it.

One should always strive for natural keys if possible. In some cases, this is not possible, but the key (Id) belongs to the object and thus should be returned.

If one is using a natural key, the save could return void as the object has not changed. If one is using an artificial key, then the save should return the PK value as part of the save operation.

  • Which one's the natural key? The DB-generated auto-increment one? – Nik Kyriakides Jul 13 '17 at 17:52
  • The DB generated one is an artificial key. A natural key is made from the data that makes up a student like first name, last name, etc. Sometimes a natural key cannot be found from the data. For example, a student first name and last name would not be a good key candidate because people have the same first/last name. – Jon Raynor Jul 13 '17 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.