This project is read-only.

ContentParts without ContentRecord?

Topics: Core, Writing modules
Jan 12, 2014 at 8:32 PM
Is it possible to create a ContentPart inside Migrations.cs without the need to create a Record and Table?

Where would the data that is part of the ContentPart be stored?

Jan 12, 2014 at 8:47 PM
Edited Jan 12, 2014 at 8:48 PM
Yes. ContentDefinitionManager.AlterPartDefinition call will create the part. Definition of the content part (metadata) is stored in Settings_ContentPartDefinitionRecord.
Jan 12, 2014 at 8:49 PM

Thanks a lot.

What's way is recommended? Creating a Record or just using Migrations to create just the part?


Jan 12, 2014 at 9:15 PM
Rather required than recommended. If the part will hold/manage its own data (other than metadata, which are part's name, its definition and whether or not it's attachable) then a DB record is necessary. For example for a content part used as a widget which will not hold any data for an instance of it, like a sign in box that would display a username password form if the request is not authenticated, the record is unnecessary since no data of the widget will be persisted. But if you want to save some setting with the widget, for example a twitter widget that shows tweets by a given twitter user name, a record is necessary to persist the twitter user name in the DB.

Alternatively you can attach fields to the part to hold the data, but in this case the part would be vulnerable to changes admin can do, i.e. removing a field. The part should not depend on fields, it's supposed to be atomic in a way. So this is not recommended.

Jan 12, 2014 at 9:17 PM
Oh great. So I could create a Part with Fields inside Migrations, then I won't need a Record, but the fields might be easily removed from the Dashboard, that's what you mean?

Jan 12, 2014 at 9:21 PM

Jan 12, 2014 at 10:03 PM
Thanks a lot.

Jan 13, 2014 at 1:15 AM
Actually you can go with parts and store data like with fields, in the infoset. The infoset is an XML document that is stored along the content item, so is always available (and doesn't need a record, but can't be simply queried). Orchard 1.8 will provide improved support for infoset storage. In the mean time you can do this.As<InfosetPart>() from you part's properties and use its Get() and Set() to storde data without a record.

Fields also use the infoset storage under the hood.
Jan 13, 2014 at 3:09 AM
Zoltan is right. It is actually recommended not to create a record, starting with Orchard 1.8, unless you have properties on the part that must be queried on. Just use Store and Retrieve from the part's property accessors.
Jan 13, 2014 at 6:30 AM
Thanks gentlemen. Any sample online to see what you are talking about?

When is the 1.8 supposed to be released?


Jan 13, 2014 at 11:28 AM
See the Force property: This part is being transitioned to infoset storage, that's why just Force is using infoset yet.

We don't have a release date for 1.8 yet but if you take a look at the roadmap in the docs you'll get an idea what is aimed for this release and what the progress is.
Jan 13, 2014 at 11:40 AM
Thanks! What's the branch that corresponds to 1.8? Is it the 1.x?

Jan 13, 2014 at 11:54 AM
One more thing, What about Records that we create and has no corresponding Parts? Would these also benefit from Infoset or the old way of creating Records and using IRepository to retrieve data?


Jan 13, 2014 at 12:44 PM
Yes, 1.x will be 1.8. Records are still needed, infoset is just for content item content storage.
Jan 13, 2014 at 12:47 PM