What is the general take on extending umbraco database.
Do you use the built in database context? or do you create a seperate project to house your needs? (As how would you create the database on the run?)
Currently i got to make a list of value pairs per member. I can see theres few ways to do this.
Create custom data type, add that to the member group as properties. (saved in umbraco)
Create custom data type and use resource.js that contacts apicontroller (extra calls tho, not really worth it unless api is required)
Use surface controller, with a view that interacts with surface controller (like normal mvc essentially)
Ofc it would be easiest to store it in umbraco since the connection between member and your own database might be tedius work to get properly running and will seperate umbraco in future version in case of change, unless you manually create sql scripts and apply them (not seen anyway to automaticly make it happen)
However, how to handle the usage of db aswell, would you create seperate project with entity framework to use, or would you use umbracos database context?
I have not seen any large projects, so im a bit confused as to how to handle it for extending/packaging.
I think you'll be okay to extend the Umbraco database and create an external project within your solution to access it via Entity Framework. I believe EF only references tables it knows about within it's context. So as long as you're not mapping Umbraco tables, you should be fine.
With regards to upgrading, as long as your custom tables within the Umbraco database do not reference Umbraco tables, you should be fine as well.
Extending Database
What is the general take on extending umbraco database.
Do you use the built in database context? or do you create a seperate project to house your needs? (As how would you create the database on the run?)
Currently i got to make a list of value pairs per member. I can see theres few ways to do this.
Create custom data type, add that to the member group as properties. (saved in umbraco)
Create custom data type and use resource.js that contacts apicontroller (extra calls tho, not really worth it unless api is required)
Use surface controller, with a view that interacts with surface controller (like normal mvc essentially)
Ofc it would be easiest to store it in umbraco since the connection between member and your own database might be tedius work to get properly running and will seperate umbraco in future version in case of change, unless you manually create sql scripts and apply them (not seen anyway to automaticly make it happen)
However, how to handle the usage of db aswell, would you create seperate project with entity framework to use, or would you use umbracos database context?
I have not seen any large projects, so im a bit confused as to how to handle it for extending/packaging.
Hi Blom,
I think you'll be okay to extend the Umbraco database and create an external project within your solution to access it via Entity Framework. I believe EF only references tables it knows about within it's context. So as long as you're not mapping Umbraco tables, you should be fine.
With regards to upgrading, as long as your custom tables within the Umbraco database do not reference Umbraco tables, you should be fine as well.
Thanks,
Dan.
is working on a reply...