public Class Company
{
public IList<Employee> Employees;
}
public Class Employee
{
public Company WorkPlace;
}
when I want to save an object of class Company:
MongoDatabase Database = MongoServer.GetDatabase("db");
var workPlace = new Company();
var employee = new Employee { WorkPalce = workPlace}
workPlace.Employees = new List<Employee>{ employee };
Database.GetCollection<Company>("company").Save(workPlace);
StackOverFlow Exception will be thrown.
The object graph being saved must not have any cycles or you will get
a StackOverflowException.
Even if it were possible you probably wouldn't want to save the entire
company as one document (think about what woud happen if the company
was very large).
For a 1 to n relationship like this I would suggest separate
collections for the Company and the Employee, and have the Employee
contain a CompanyId. You probably don't want the Company to contain a
list of EmployeeIds. You can always get the list by querying the
Employee collection by CompanyId.
> --
> You received this message because you are subscribed to the Google Groups "mongodb-user" group.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.
>
and there are some additional answers there.
https://github.com/impetus-opensource/Kundera
On Dec 12, 7:36 am, Robert Stam <rob...@10gen.com> wrote:
> This question was also asked on stackoverflow:
>
> http://stackoverflow.com/questions/8461996/save-an-object-with-a-bidi...
>
> and there are some additional answers there.
>
> On Sun, Dec 11, 2011 at 1:18 AM, Robert Stam <rob...@10gen.com> wrote:
> > This is not currently possible.
>
> > The object graph being saved must not have any cycles or you will get
> > a StackOverflowException.
>
> > Even if it were possible you probably wouldn't want to save the entire
> > company as one document (think about what woud happen if the company
> > was very large).
>
> > For a 1 to n relationship like this I would suggest separate
> > collections for the Company and the Employee, and have the Employee
> > contain a CompanyId. You probably don't want the Company to contain a
> > list of EmployeeIds. You can always get the list by querying the
> > Employee collection by CompanyId.
>