Hi Markus!

Thanks for your feedback. As my application is based on a legacy
database which does not allow nullable foreign keys, using the
bidirectional approach seems to be a good solution.
However, I'm still a bit confused about this behaviour as think it was
different in previous AR versions? I also read an article about
superfluous updates at nhprof.com (http://nhprof.com/Learn/Alert?
name=SuperfluousManyToOneUpdate) and I thought I had understood it -
but it seems that I had not :-) Or did I miss a thing?


Best Regards

Markus


On 17 Okt., 14:50, Markus Zywitza <[email protected]> wrote:
> Hi Markus
> when you use Inverse=true, the Collection won't be inspected for changes.
> The Cascade option looks into the orders and saves them if they are
> transient, but the Orders property should be treated as read-only. Inverse
> means that the relation is managed by the other end of the relation, hence
> this behaviour,
>
> When you need a not nullable FK, you must use Inverse=true and use a
> property on Order referencing Customer.
>
> -Markus
>
> 2009/10/16 Markus <[email protected]>
>
>
>
> > Hi all!
>
> > I experience a problem when using HasMany-associations with the latest
> > AR 2.0. To illustrate the problem, I created a simple Customer and
> > Order class, where each Customer has n Orders and each Order belongs
> > to 1 Customer. My classes look like that:
>
> >    [ActiveRecord("Customers")]
> >    public class Customer : ActiveRecordBase<Customer>
> >    {
> >        [PrimaryKey(PrimaryKeyType.Native, Access =
> > PropertyAccess.Property)]
> >        public long Id { get; set; }
>
> >        [Property(NotNull = true)]
> >        public string Name { get; set; }
>
> >        [HasMany(typeof(Order),
> >                Table = "Orders",
> >                ColumnKey = "CustomerId",
> >                Cascade = ManyRelationCascadeEnum.All,
> >                RelationType = RelationType.Bag,
> >                Access = PropertyAccess.Property,
> >                Inverse = true)]
> >        public IList<Order> Orders { get; set; }
> >    }
>
> >    [ActiveRecord("Orders")]
> >    public class Order : ActiveRecordBase<Order>
> >    {
> >        [PrimaryKey(PrimaryKeyType.Native, Access =
> > PropertyAccess.Property)]
> >        public long Id { get; set; }
>
> >        [Property(NotNull = true)]
> >        public DateTime Date { get; set; }
> >    }
>
> > I create a new customer using these lines of code:
> >  var c = new Customer();
> >  c.Name = "ALFKI";
> >  c.Orders = new List<Order>();
> >  c.Orders.Add(new Order { Date = DateTime.UtcNow });
> >  c.SaveAndFlush();
>
> > The SQL commands that are generated are (tested with SQLite):
> > NHibernate: INSERT INTO Customers (Name) VALUES (@p0); select
> > last_insert_rowid();@p0 = 'ALFKI'
> > NHibernate: INSERT INTO Orders (Date) VALUES (@p0); select
> > last_insert_rowid();@p0 = 16.10.2009 00:00:00
>
> > As you can see, the INSERT statement for the Orders table does not set
> > the foreign key for the customer. If I set the 'Inverse' attribute of
> > the Orders collection to 'false', the following SQL is generated:
>
> > NHibernate: INSERT INTO Customers (Name) VALUES (@p0); select
> > last_insert_rowid();@p0 = 'ALFKI'
> > NHibernate: INSERT INTO Orders (Date) VALUES (@p0); select
> > last_insert_rowid();@p0 = 16.10.2009 00:00:00
> > NHibernate: UPDATE Orders SET CustomerId = @p0 WHERE Id = @p1;@p0 = 1,
> > @p1 = 1
>
> > Now the foreign key is set at least, although this is not a desirable
> > behaviour as it 1) leads to a superfluous SQL statement and 2) the
> > foreign key in the Orders table should not allow NULLs. How could I
> > solve this issue? Is it a bug?
>
> > Best Regards
>
> > Markus
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to