It’s not very clear how idProperty is used in the data store when building a data model. The documentation says “If the store has a single primary key, this indicates the property to use as the identity property. The values of this property should be unique. This defaults to "id".
Is this assuming the schema from which the model is based, has a mostly flat structure? For example an array of objects – each with an identity property?
What if the schema is not a simple array but has more complex structure starting from a single object that contains several sub levels of properties within properties. OR is just multiple arrays on the same level where each group of arrays identify property are independent of one another?
A store is an extension of a collection.
A collection is the interface for a collection of items (your obect with a potentially complex schema).
You can use Custom Querying on a collection to define special queries to find your data with any subset of properties.
In short, yes you can querying your data even if it has a custom schema but you need to define a Custom Querying.
More info can be found here at the end of the article: https://github.com/SitePen/dstore/blob/master/docs/Collection.md
Currently I have a table "ComponentAnalysis" and a table "HistoryOfUse" that I am trying to map in Fluent NHibernate.
A component analysis should only have 1 history of use and a history of use should belong to 1 component analysis. This would suggest to me that the tables should be set up for a 1 to 1 mapping. But the designer of the DB didn't set it up that way.
Instead "HistoryOfUse" has a column "ComponentAnalysisID" to specify what component analysis it belongs to. To conform to the database I should have HistoryOfUse References ComponentAnalysis and ComponentAnalysis should HasMany HistoryOfUse.
But if I do this then I need to have a list of type HistoryOfUse which seems fairly annoying. Is there a way to set this up, without changing the database, to allow ComponentAnalysis to have a single HistoryOfUse object even though, according to the DB structure, it should have a list of them?
You can use HasOne method to map your classes. Here is the detailed article about this.
Your class ComponentAnalysis will "HasOne(x => x.HistoryOfUse)". Column HistoryOfUse.ComponentAnalysisID should be a unique key and a foreign key referenced to the ComponentAnalysis.ID column.
I have a users table that is updated by other systems. I have mapped the table to my users objects and that work great. As user data is owned by another system I don't want to change the structure of that table.
I want to add metadata to the user objects, but without changing the structure of the users table. I want to add a flag that tells me whether the user is an administrator or not. I think this flag could be stored in a table that only has one column which is the id of the user. whether a matching row is present would be represented as a boolean property on the user.
Is it possible to map this in NHibernate? I would like it so that I can update this directly through NHibernate.
You should investigate the <join> mapping, usage is described in this article.
I have a scenario where I want to persist document info record to a table specific to the typo of document, rather than a generic table for all records.
For example, records for Invoices will be stored in dbo.Doc_1000 and records for Receipts will be stored in dbo.Doc_2000 where 1000 and 2000 are id autogenerate and store in well-known table (dbo.TypeOfDoc.
Furthermore each dbo.Doc.xxx table have a group of system column (always the same) and could have a group of dynamic column (metadata).
Tables dbo.Doc.xxx and eventually dynamic column are clearly created at runtime.
If this is possible with NHibernate???
Thanks.
hope that I got your point. I am currently looking for a solution for a problem that looks similar. I want to integrate a feature in my application where the admin user can design an entity at runtime.
As far as I know, once the SessionFactory is configured and ready to use, there is no way to modify the mapping used by nhibernate. If you want to use a customized table structure that is configured, created and modified at runtime, you should have a place where a corresponding mapping lives, e.g. as a nhibernate mapping xml file and you have to set up a new SessionFactory each time you change the database model to reflect these changes.
I am creating the model for a web application. The tables have ID fields as primary keys. My question is whether one should define ID as a property of the class?
I am divided on the issue because it is not clear to me whether I should treat the object as a representation of the table structure or whether I should regard the table as a means to persist the object.
If I take the former route then ID becomes a property because it is part of the structure of the database table, however if I take the latter approach then ID could be viewed as a peice of metadata belonging to the database which is not strictly a part of the objects model.
And then we arrive at the middle ground. While the ID is not really a part of the object I'm trying to model, I do realise that the the objects are retrieved from and persisted to the database, and that the ID of an object in the database is critical to many operations of the system so it might be advantageous to include it to ease interactions where an ID is used.
I'm a solo developer, so I'd really like some other, probably more experienced perspectives on the issue
Basically: yes.
All the persistence frameworks ive used (including Hibernate, Ibatis) do require the ID to be on the Object.
I understand your point about metadata, but an Object from a database should really derive its identity in the same way the database does - usually an int primary key. Then Object-level equality should be derived from that.
Sometimes you have primary keys that are composite, e.g first name and last name (don't ever do this!), in which cases the primary key doesn't become 'metadata' because it is part of the Object's identity.
I generally reserve the ID column of an object for the database. My opinion is that to use it for any 'customer-facing' purpose, (for example, use the primary key ID as a customer number) you will always shoot yourself in the foot later.
If you ever make changes to the existing data (instead of exclusively adding new data), you need the PK. Otherwise you don't know which record to change in the DB.
You should have the ID in the object. It is essential.
The easiest use case to give as an example is testing equality:
public bool Equals(Object a, Object b) { return {a.ID = b.ID}; }
Anything else is subject to errors, and you'll find that out when you start getting primary key violations or start overwriting existing data.
By counterargument:
Say you don't have the ID in the object. Once you change an object, and don't have it's ID from the database, how will you know which record to update?
At the same time, you should note that the operations I mention are really private to the object instance, so ID does not necessarily have to be a public property.
I include the ID as a property. Having a simple unique identifier for an object is often very handy regardless of whether the object is persisted in a database or not. It also makes your database queries much more simple.
I would say that the table is just a means to persist an object, but that doesn't mean the object can't have an ID.
I'm very much of the mindset that the table is a means to persist the object, but, even so, I always expose the IDs on my objects for two primary reasons:
The database ID is the most convenient way to uniquely identify an object, either within a class (if you're using a per-table serial/autonumber ID) or universally (if you're maintaining a separate "ID-to-class" mapping). In the context of web applications, it makes everything much simpler and more efficient if your forms are able to just specify <input type=hidden name=id value=12345> instead of having to provide multiple fields which collectively contain sufficient information to identify the target object (or, worse, use some scheme to concatenate enough identifying information into a single string, then break it back down when the form is submitted).
It needs to have an ID anyhow in order to maintain a sane database structure and there's no reason not to expose it.
Should the ID in the object read-only or not? In my mind it should be read-only as by definition the ID will never change (as it uniquely identifies a record in the database).
This creates a problem when you create a new object (ID not set yet), save it in the database through a stored procedure which returns the newly created ID then how do you store it back in the object if the ID property is read-only?
Example:
Employee employee = new Employee();
employee.FirstName="John";
employee.LastName="Smith";
EmployeeDAL.Save(employee);
How does the Save method (which actually connects to the database to save the new employee) update the EmployeeId property in the Employee object if this property is read-only (which should be as the EmployeeId will never ever change once it's created).