How do I persist a primitive array with nHibernate

Given this entity:

public class Product
{

  public double[] Prices;
}

With this table structure:

Product (Id)
Price (ProductId, Order, Price)

I'm confused as to the difference between when to use a list, a bag, a primitive array, an array, etc. 开发者_开发知识库I couldn't find much explanation on the primitive array.

An important requirement is that the array items should always be stored and retrieved in the same order and may contain duplicate values.

My question is, how would the mapping look between these two tables?

In order to preserve the order you need a <list/>, and provide an indexing column to keep track of the element ( or entity ) order. You can have a list of element ( simple types ) that seems to fit better your needing.

If you know for sure your data will never have inconsistent array data as prices (index starting always at 0 for all products, never any prices index holes or duplicates for a product), map it as an <array>.

(And better switch your prices to decimal type instead of double.)

<class name="Product">
    <id name="Id"  generator="..." />
    <array name="Prices" table="Price">
        <key column="ProductId" />
        <index column="Order"/>
        <element type="decimal" length="19" precision="4">
            <column name="Price" />
        </element>
    </array>
</class>

You may also use a list instead as written in Felice's answer, but then type your property as an IList<decimal>.

As for primitive-array, it looks like we just do not have to bother with it, this is a mapping inherited from java Hibernate and corresponding to a notion, primitive, not relevant in C#.
This was probably the meaning of Paco's comment, which I have not understood at first. It seems confirmed by this NH issue.

If you cannot guarantee index coherence in DB (not always starting at 0, may have holes or duplicated indexes for a same product, ...), then you will have to change your model for mapping your prices as a <set> of children entities (ISet<Price> Prices) with an index you will handle by your own code. (The ordering part when loading data could be handled by an order-by="Order" attribute on your set mapping.)
Duplicated prices for a product will be distinct rows in DB too, for handling the index which would be different. Thus my recommandation of using a set rather than a bag, since duplicated prices would be indeed different entities.