OneToMany Spring Data JDBC

I want to model a OneToMany Relation with Spring Data JDBC. I´ve read on this very useful blog https://spring.io/blog/2018/09/24/spring-data-jdbc-references-and-aggregates that you should use references when you want to model ToMany Reference:

Therefore any Many-to-One and Many-to-Many relationship must be modeled by just referencing the id.

So I have this scenario:

One Student can have multiple Registration. And one Registration can have exactly one Student. If you delete Registration the assigned Student should not get deleted cascading.

I ended up with this modelling:

@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Registration {



    private final @Id

    @Wither

    long registrationId;



    @NotNull

    private String electiveType;



    @NotNull

    private LocalDateTime created = LocalDateTime.now();



    @NotNull

    private StudentRegistrationReference studentRegistrationReference;



}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class StudentRegistrationReference {

    private long student;

    private long registration;

}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Student {



    private final @Id

    @Wither

    long studentId;



    @NotNull

    @Size(min = 4, max = 20)

    private String userId;



    @NotNull

    @Min(0)

    private int matriculationNumber;



    @NotNull

    @Email

    private String eMail;



    private Set<StudentRegistrationReference> studentRegistrationReferences = new HashSet<>();



}

My question is whether my modeling is correctly implemented?

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

asked Nov 19 '18 at 13:52

Thomas Lang

11717

add a comment |

Therefore any Many-to-One and Many-to-Many relationship must be modeled by just referencing the id.

@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Registration {



    private final @Id

    @Wither

    long registrationId;



    @NotNull

    private String electiveType;



    @NotNull

    private LocalDateTime created = LocalDateTime.now();



    @NotNull

    private StudentRegistrationReference studentRegistrationReference;



}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class StudentRegistrationReference {

    private long student;

    private long registration;

}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Student {



    private final @Id

    @Wither

    long studentId;



    @NotNull

    @Size(min = 4, max = 20)

    private String userId;



    @NotNull

    @Min(0)

    private int matriculationNumber;



    @NotNull

    @Email

    private String eMail;



    private Set<StudentRegistrationReference> studentRegistrationReferences = new HashSet<>();



}

My question is whether my modeling is correctly implemented?

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

asked Nov 19 '18 at 13:52

Thomas Lang

11717

add a comment |

Therefore any Many-to-One and Many-to-Many relationship must be modeled by just referencing the id.

@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Registration {



    private final @Id

    @Wither

    long registrationId;



    @NotNull

    private String electiveType;



    @NotNull

    private LocalDateTime created = LocalDateTime.now();



    @NotNull

    private StudentRegistrationReference studentRegistrationReference;



}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class StudentRegistrationReference {

    private long student;

    private long registration;

}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Student {



    private final @Id

    @Wither

    long studentId;



    @NotNull

    @Size(min = 4, max = 20)

    private String userId;



    @NotNull

    @Min(0)

    private int matriculationNumber;



    @NotNull

    @Email

    private String eMail;



    private Set<StudentRegistrationReference> studentRegistrationReferences = new HashSet<>();



}

My question is whether my modeling is correctly implemented?

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

asked Nov 19 '18 at 13:52

Thomas Lang

11717

Therefore any Many-to-One and Many-to-Many relationship must be modeled by just referencing the id.

@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Registration {



    private final @Id

    @Wither

    long registrationId;



    @NotNull

    private String electiveType;



    @NotNull

    private LocalDateTime created = LocalDateTime.now();



    @NotNull

    private StudentRegistrationReference studentRegistrationReference;



}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class StudentRegistrationReference {

    private long student;

    private long registration;

}



@Data

@AllArgsConstructor(access = AccessLevel.PRIVATE, onConstructor = @__(@PersistenceConstructor))

public class Student {



    private final @Id

    @Wither

    long studentId;



    @NotNull

    @Size(min = 4, max = 20)

    private String userId;



    @NotNull

    @Min(0)

    private int matriculationNumber;



    @NotNull

    @Email

    private String eMail;



    private Set<StudentRegistrationReference> studentRegistrationReferences = new HashSet<>();



}

My question is whether my modeling is correctly implemented?

java spring-data software-design spring-data-jdbc

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

asked Nov 19 '18 at 13:52

Thomas Lang

11717

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

asked Nov 19 '18 at 13:52

Thomas Lang

11717

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

edited Nov 19 '18 at 14:47

Jens Schauder

45.7k17112236

asked Nov 19 '18 at 13:52

Thomas Lang

11717

asked Nov 19 '18 at 13:52

Thomas Lang

11717

asked Nov 19 '18 at 13:52

Thomas Lang

11717

add a comment |

1 Answer
1

active

oldest

votes

You are quoting the article talking about "Many-To-X" but you talk yourself about "X-To-Many". You can model a One-To-One or a One-To-Many relationship with a direct reference, or a List/Set/Map of entities.

What you should avoid are bidirectional relationships. While you probably can make them work with the approach you are using, you really shouldn't.

Which brings us to the question: How should this model look like?

The central decision to make is how many aggregates are involved?

A Student certainly is an aggregate and the Student class is its aggregate root. It can exist on its own.

But what about Registration? I'd argue, it is probably part of the same aggregate. The delete test is a good one. If you delete a Student from the system, do the registrations of that Student still have value? Or should the disappear together with the Student?

As an exercise let's do both variants. I start with: Just one aggregate:

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

    Set<Registration> registrations = new HashSet<>();

}

With this, you would have a single repository:

interface StudentRepository extends CrudRepository<Student, Long>{}

I removed all the Lombok annotations since they aren't really relevant to the problem. Spring Data JDBC can operate on simple attributes.

If Registration and Student both are aggregates it gets a little more involved:
You need to decide which side owns the reference.

First case: The Registration owns the reference.

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();



    Long studentId;

}



public class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

}

Second case: The Student owns the reference

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;



    Set<RegistrationRef> registrations = new HashSet<>();

}



class RegistrationRef {



    Long registrationId;

}

Note that the RegistrationRef doesn't have a studentId or similar. The table assumed for the registrations property will have a student_id column.

edited Nov 20 '18 at 6:13

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the Student by the IStudentRepostory will the Set<RegistrationRef> being fetched with the Registration Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC?
– Thomas Lang
Nov 20 '18 at 6:10

"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet).
– Jens Schauder
Nov 20 '18 at 6:14

This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help!
– Thomas Lang
Nov 20 '18 at 6:21

Can you also share the final SQL table definitions?
– G.Mast
Dec 5 '18 at 22:08

I need a complete picture, a quick look at stackoverflow.com/questions/53638091/… is much appreciated.
– G.Mast
Dec 5 '18 at 23:23

|
show 1 more comment

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53376101%2fonetomany-spring-data-jdbc%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

What you should avoid are bidirectional relationships. While you probably can make them work with the approach you are using, you really shouldn't.

Which brings us to the question: How should this model look like?

The central decision to make is how many aggregates are involved?

A Student certainly is an aggregate and the Student class is its aggregate root. It can exist on its own.

As an exercise let's do both variants. I start with: Just one aggregate:

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

    Set<Registration> registrations = new HashSet<>();

}

With this, you would have a single repository:

interface StudentRepository extends CrudRepository<Student, Long>{}

I removed all the Lombok annotations since they aren't really relevant to the problem. Spring Data JDBC can operate on simple attributes.

If Registration and Student both are aggregates it gets a little more involved:
You need to decide which side owns the reference.

First case: The Registration owns the reference.

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();



    Long studentId;

}



public class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

}

Second case: The Student owns the reference

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;



    Set<RegistrationRef> registrations = new HashSet<>();

}



class RegistrationRef {



    Long registrationId;

}

Note that the RegistrationRef doesn't have a studentId or similar. The table assumed for the registrations property will have a student_id column.

edited Nov 20 '18 at 6:13

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the Student by the IStudentRepostory will the Set<RegistrationRef> being fetched with the Registration Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC?
– Thomas Lang
Nov 20 '18 at 6:10

"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet).
– Jens Schauder
Nov 20 '18 at 6:14

This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help!
– Thomas Lang
Nov 20 '18 at 6:21

Can you also share the final SQL table definitions?
– G.Mast
Dec 5 '18 at 22:08

I need a complete picture, a quick look at stackoverflow.com/questions/53638091/… is much appreciated.
– G.Mast
Dec 5 '18 at 23:23

|
show 1 more comment

What you should avoid are bidirectional relationships. While you probably can make them work with the approach you are using, you really shouldn't.

Which brings us to the question: How should this model look like?

The central decision to make is how many aggregates are involved?

A Student certainly is an aggregate and the Student class is its aggregate root. It can exist on its own.

As an exercise let's do both variants. I start with: Just one aggregate:

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

    Set<Registration> registrations = new HashSet<>();

}

With this, you would have a single repository:

interface StudentRepository extends CrudRepository<Student, Long>{}

I removed all the Lombok annotations since they aren't really relevant to the problem. Spring Data JDBC can operate on simple attributes.

If Registration and Student both are aggregates it gets a little more involved:
You need to decide which side owns the reference.

First case: The Registration owns the reference.

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();



    Long studentId;

}



public class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

}

Second case: The Student owns the reference

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;



    Set<RegistrationRef> registrations = new HashSet<>();

}



class RegistrationRef {



    Long registrationId;

}

Note that the RegistrationRef doesn't have a studentId or similar. The table assumed for the registrations property will have a student_id column.

edited Nov 20 '18 at 6:13

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the Student by the IStudentRepostory will the Set<RegistrationRef> being fetched with the Registration Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC?
– Thomas Lang
Nov 20 '18 at 6:10

"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet).
– Jens Schauder
Nov 20 '18 at 6:14

This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help!
– Thomas Lang
Nov 20 '18 at 6:21

Can you also share the final SQL table definitions?
– G.Mast
Dec 5 '18 at 22:08

I need a complete picture, a quick look at stackoverflow.com/questions/53638091/… is much appreciated.
– G.Mast
Dec 5 '18 at 23:23

|
show 1 more comment

What you should avoid are bidirectional relationships. While you probably can make them work with the approach you are using, you really shouldn't.

Which brings us to the question: How should this model look like?

The central decision to make is how many aggregates are involved?

A Student certainly is an aggregate and the Student class is its aggregate root. It can exist on its own.

As an exercise let's do both variants. I start with: Just one aggregate:

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

    Set<Registration> registrations = new HashSet<>();

}

With this, you would have a single repository:

interface StudentRepository extends CrudRepository<Student, Long>{}

I removed all the Lombok annotations since they aren't really relevant to the problem. Spring Data JDBC can operate on simple attributes.

If Registration and Student both are aggregates it gets a little more involved:
You need to decide which side owns the reference.

First case: The Registration owns the reference.

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();



    Long studentId;

}



public class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

}

Second case: The Student owns the reference

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;



    Set<RegistrationRef> registrations = new HashSet<>();

}



class RegistrationRef {



    Long registrationId;

}

Note that the RegistrationRef doesn't have a studentId or similar. The table assumed for the registrations property will have a student_id column.

edited Nov 20 '18 at 6:13

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

What you should avoid are bidirectional relationships. While you probably can make them work with the approach you are using, you really shouldn't.

Which brings us to the question: How should this model look like?

The central decision to make is how many aggregates are involved?

A Student certainly is an aggregate and the Student class is its aggregate root. It can exist on its own.

As an exercise let's do both variants. I start with: Just one aggregate:

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

    Set<Registration> registrations = new HashSet<>();

}

With this, you would have a single repository:

interface StudentRepository extends CrudRepository<Student, Long>{}

I removed all the Lombok annotations since they aren't really relevant to the problem. Spring Data JDBC can operate on simple attributes.

If Registration and Student both are aggregates it gets a little more involved:
You need to decide which side owns the reference.

First case: The Registration owns the reference.

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();



    Long studentId;

}



public class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;

}

Second case: The Student owns the reference

class Registration {



    @Id private long Id;



    String electiveType;

    LocalDateTime created = LocalDateTime.now();

}



class Student {



    @Id private long Id;



    String userId;

    int matriculationNumber;

    String eMail;



    Set<RegistrationRef> registrations = new HashSet<>();

}



class RegistrationRef {



    Long registrationId;

}

Note that the RegistrationRef doesn't have a studentId or similar. The table assumed for the registrations property will have a student_id column.

edited Nov 20 '18 at 6:13

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

edited Nov 20 '18 at 6:13

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

answered Nov 19 '18 at 15:24

Jens Schauder

45.7k17112236

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the Student by the IStudentRepostory will the Set<RegistrationRef> being fetched with the Registration Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC?
– Thomas Lang
Nov 20 '18 at 6:10

"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet).
– Jens Schauder
Nov 20 '18 at 6:14

This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help!
– Thomas Lang
Nov 20 '18 at 6:21

Can you also share the final SQL table definitions?
– G.Mast
Dec 5 '18 at 22:08

I need a complete picture, a quick look at stackoverflow.com/questions/53638091/… is much appreciated.
– G.Mast
Dec 5 '18 at 23:23

|
show 1 more comment

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the Student by the IStudentRepostory will the Set<RegistrationRef> being fetched with the Registration Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC?
– Thomas Lang
Nov 20 '18 at 6:10

"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet).
– Jens Schauder
Nov 20 '18 at 6:14

This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help!
– Thomas Lang
Nov 20 '18 at 6:21

Can you also share the final SQL table definitions?
– G.Mast
Dec 5 '18 at 22:08

I need a complete picture, a quick look at stackoverflow.com/questions/53638091/… is much appreciated.
– G.Mast
Dec 5 '18 at 23:23

Thank you Jens for your answer. Your explanation and your example do make the principle clear. I will try that out with tests. I have just two more questions not being directly related to the original question, but somehow allied to it: 1. Second case: when i load the Student by the IStudentRepostory will the Set<RegistrationRef> being fetched with the Registration Ids? 2. You have mentioned table generated/generation in the above answer. How does that work out with Spring Data JDBC?
– Thomas Lang
Nov 20 '18 at 6:10

"generated" was the wrong word. "expected" or "assumed" is the correct wording. Spring Data JDBC doesn't do table generation (yet).
– Jens Schauder
Nov 20 '18 at 6:14

This (auto-generation of the database) would be a killer feature :) but nevertheless - thank you for your clarification and your help!
– Thomas Lang
Nov 20 '18 at 6:21

Can you also share the final SQL table definitions?
– G.Mast
Dec 5 '18 at 22:08

I need a complete picture, a quick look at stackoverflow.com/questions/53638091/… is much appreciated.
– G.Mast
Dec 5 '18 at 23:23

|
show 1 more comment

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu