I wasn’t sure where to put this on the forum as there is no
roadmap/strategy page so I guess this is the best place.
I have allot of time for Umbraco. Its fast and flexible but
there is one gripe that keeps on haunting me. I have ranted about it before and
guess what I am going to do it again.
We use the pro licensed version and I was excited to get concierge
working, only to find it is slow to the point of timeouts on most reports :-(
then my gripe kicked in 'its the database, the database!'. Naively thinking a
couple of indexes would solve my issues I fired off performance analyser and
was horrified.
To view all Saved log entries using concierge takes about
15 seconds on our development server (using productive data). Now in my case
indexes won’t help because under the bonnet of umbraco tiny SQL statements
are fired off manny times (almost recursively). DB's have an overhead when executing
SQL meaning the less queries the better (yes I know this can be argued..). Whilst joins
are amongst most costly operations in a db, a db can do joins allot better that
developers can do in code. Partly due to the lack of joins to report a log containing 6000
page saves concierge feels the need to fire off 30,000 SQL transactions (no
that is not a typo). This is what takes 15 seconds. The problem is not Concierge
it’s the API Concierge uses in other words the guts of the machine.
FYI here is 1 query that gets the same data* in under a
second**:
declare @HeaderType nvarchar(50) set @HeaderType=N'Save' SELECT distinct @HeaderType as Type ,[Datestamp] as [Date/time] ,case when [published]=0 then null else nod.Text end as Page ,usr.[userName] as [User] ,[logComment] as [Comment] FROM [dbo].[umbracoLog] lo left outer join [dbo].[umbracoNode] nod on nod.[id]=lo.[NodeId] left outer join [dbo].[umbracoUser] usr on lo.[userId]=usr.[id] left outer join [dbo].[cmsDocument] doc on lo.[NodeId]=doc.nodeId where [logHeader] = 'save' order by dateStamp DESC
*Same data from what I can tell however there is a lot of
stuff going on with versioning that seams irrelevant for the particular ‘Save’ report
as the only data returned that can change with versions is the node name and
Umb doesn’t version node names.
**There is allot more room for improvement with some much
needed schema changes but don’t get me started there..
Yes I am a db guy and not a developer, I don’t have to talk
about the object relational mismatch Google has plenty on that. The fact is the
backend of umbraco uses a database really badly and that makes me frightened
when we think about scalability and longevity.
In the past I have mentioned this and I have had the response
'Umbraco is open source' so get involved :-). That shut me up. Partly because
after work and family I can’t find the time to clean the car let alone donate
my time to an 'open source' project but also because Umbraco is not really open
source. Rather it is free with source code available, for example the rendering
engine and the API are licence. There is a small number of core developers (11 actually
with 7 active since June 9th) and the code is available so people can help
improve it and find bugs but the ownership is firmly private. From what I can
tell there is absolutely nothing to stop the project turning closed source and
100% commercial in the future. Perhaps this will never happen but it could, if
it did perhaps this would be for the best I don’t know.
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;
mso-font-charset:1;
mso-generic-font-family:roman;
mso-font-format:other;
mso-font-pitch:variable;
mso-font-signature:0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-1610611985 1073750139 0 0 159 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}
span.EmailStyle15
{mso-style-type:personal;
mso-style-noshow:yes;
mso-style-unhide:no;
mso-ansi-font-size:11.0pt;
mso-bidi-font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;
mso-fareast-language:EN-US;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
Now I am guessing I am not the only person who realizes that
and that this is the reason whilst although the Umbraco community is steadily growing
the number of people actively involved in the core project remains the same.
My last paragraph is off on a tangent so back to my gripe.
The db and how Umbraco uses the db sucks. For me it is the biggest
restriction of the system and poses the biggest risk to the project. I have
read that Umbraco 5 will use MVP and perhaps this will finally kill my gripe.
However until then for me umbraco remains a nice tool for solving simple
problems that has an uncertain future.
Alec: MVPs directly in Umbraco? How do they fit in there? ;)
No seriously, you need to elaborate a bit on your critisism if you want constructive answers. You say the db and how umbraco uses it sucks, I am no db guy so I can't tell if you're right or not, but I do know that there has been discussions about the db because it has some .. hmm.. shortcomings (lack of indexes and such). But if you have the time for it, I encourage you to submit patches or contact the core group and offer your help, rather than just complaining ;)
Sorry to break in with a somewhat off-topic question. Alec what software do you use to monitor the SQL transactions and queries that are being executed by Umbraco? I am looking for a tool to optimize an application that uses linq2sql extensively. I know about the SQL Analyzer but I am not really a DB guy and haven't found a good enough reason to invest in it. Therefore I am curious if there might be a cheaper alternative?
@Simon - I think Alec means the ASP.NET mvc framework and not MVP. This will potentially "enforce" better practices in data access (maybe using ORM technology like nHibernate with 2 caching layers), possibly making SELECT N+1 scenarios (which I assume the highlighted issue is) easier to pick up while developing.
@Alec - Correct me if I'm wrong, but as I see it Concierge is a Pro-licensed add on, so this probably means that your open source comments are irrelevant. I would however suggest you log this as an issue under your Pro support contract. The issue itself may be in the Umbraco core, but if a commercially supported product is not working, I would suggest it isn't necessarily your place to find the problem. (Although I appreciate that isn't in the spirit of the community Umbraco has).
I've few suggestions to help at this stage, other than ensuring your DB is on same server as the web server to factor out network latency in your high transaction volumes. Maybe enable only shared memory?
All Actually I did mean MVP as in Model-view-presenter not Most Valuable Professional I don’t think our server could handle that. Though I honestly don’t know much about MVC or MVP (I’m not a developer) but I understand the basic concept.
Simon I could spend quite some time elaborating and perhaps I will some other night but as for getting an 'answer to my question' I didn’t actually ask one it was a gripe post a statement if you wish. I know there are others who share my view and if anything I was hoping to stir them up a little. I don’t really have time but I could be persuaded to get involved though I wouldn’t want to do it alone for the single reason it’s quite a complex task to do correctly. Especially if you get into probable feature creep requests such as versioning of non content stuff like macros and decent membership solution etc. My fear would be that it would take me so long alone that impatient developers would invent additional solutions in parallel and the thing would never be done with. Also such a task would need keen involvm,ent from the application coders who would implement the relevant changes in the application.
bjawnie I use SQL Server Profiler. It comes with SQL server 2005 (perhaps with express also but I don’t use that)
Chris MVP/MVC you got it. But you also mention something key in using the phrase "potentially 'enforce' better practices in data access". But not necessarily. As for ORM I am bias but I am not a great fan as the limited experience I have is that the schema of ORM solutions can change quite allot between versions which is not an issue if only one application uses the db. I know Object relational mapping is not perfect but there has to be a balance and being a db guy enforcement of referential integrity and performance should not be left to the application level code and memory cashing.
Yes the open source comments is irrelevant.. sort of. The concierge package it has not lived up to my expectations in more ways than one, it’s a useful tool but it isn’t professionally finished which I can live with from open source but not when you pay for it. My comments about open source where off topic yes, but they where there because I would expect an open source project to be made up of a decent mix of people specialising in various areas application development, testers, documenters db gus n girls but umb appears to be mainly c# guys n girls. From what I can tell looking at other SQL Server Profiler reports the issue is not with concierge its the umb API/business objects that concierge uses, i.e. the same one as for pro as for the free version of umb. Doing almost any operation in the admin end of umb executes 100's or 1000's of SQL queries when only a handful are really needed. I imagine that this is because some properties only get the data they need when they need it using very granular SQL statements. Because OO can eat up memory objects are destroyed and created with their required child objects on demand resulting in all these SQL entries. MVC should help because as I understand the data access happened in one place for each model and this allow the developer to look at the bigger picture of that the model needs regarding data and when rather that selecting 1000 node name's using a thousand statements one can be used.
Thanks for the suggestion I know it would help but that our architecture though its also no excuse our other much larger highly transactional systems do just fine with the minimal latency we have.
Alec I'm guessing the reason this is happening is due to a leaky abstraction. The API code wraps up all the calls to the DB and returns objects which every one elses code can use free from the worry about SQL statements and schemas. But then used in anger it can cause a mass of SQL statements which seem un-needed. This is the pay off for an easy to use API.
Some queries could/should be optimised but then you risk spreading you db interface around and having loads of one off queries making maintenance and future mods more difficult. Its a fine balance.
1) The way Umbraco uses the DB sucks, but have been improved over the past versions and will be more improved with 4.1. Making a better DB Schema is needed, but would also break all existing installations so it's something that we've wanted to put on hold until v5. It is something that does have the attention from the core's and it's not something we ignore. As it doesn't affect a running site, it hasn't been on the top of the list (ie. the Umbraco runtime doesn't query the db).
2) Quote: "From what I can
tell there is absolutely nothing to stop the project turning closed source and
100% commercial in the future.", while this is true it would mean the death of Umbraco and luckily there's no such thing as a retroperspective license, which means that any OSS'ed version of Umbraco would still be OSS and can be improved. Make no mistake, Umbraco will never be closed sourced.
To emphasize the above; any OSS project can change its license as long as it has the permissions to do that, no matter the license. This goes for MIT (Umbraco), GPL or any other license. In the case that the owners decide to change the license it'll only affect any future version of the product and the existing version can then be forked by anyone to continue the project.
And to re-emphasize; We'll never, ever, ever turn Umbraco away from being open source. In fact we'd love to make sure that the UI could be under an open source license as well, we're just waiting for OSI to approve a license that protects branding. The main reason that the UI is not open source is that if it was MIT'ed we'd be under the risk of an "evil", unconstructive commercial fork where companies would take Umbraco re-skin it and package it without us being a little start-up without funding have any chance to defend ourselves. The current license structure was a result of advicing from Martin von Haller Grønbæk one of the leading open source lawyers in Europe. It's done as liberal as possible and hopefully it'll be even more liberal in the (near) future.
slace Original post is not a patch but I think you know that
Peter Firstly Excellent article bookmarked!, Secondly 'Its a fine balance' I understand this though would perhaps say that if we can predict certain common behaviours then we can build specific operations for those behaviours. We can have the easy to use APS (with its issues) and a set of robust less granular operations from common workflows.
Niels Firstly a new schema need not break existing installations if either a) there is a good well tested migration script or b) if a db 'abstraction layer' where made to emulate the old interface. A is probably the easiest to do as b would be a pain in the but involving lots of t-sql and triggers (not to mention the other supported db's). Thirdly I am happy that this has the attention of the core for v5 and hope there are some good db heads in the group, I would be happy to review the schema (free of charge :-)) lastly I am happy to read you OS statements and have subsequently tattooed them on my forehead :-)
Question about the v5 db (is it going to be from scratch or a series of fixes) either would work but it influences weather I (and hopefully others) can get involved now or not.
And lastly just to follow up on your comments on Concierge:
Very valid points, the slowness in the log-viewer will be solved in the next maintance release so people with more then a 1000 log items can use the viewer as well, without any performance issues. Will put together some more efficient SQL to fetch the log-items (which can then hopefully be merged into the core later) instead of using the current api.
Thanks for posting your issues, makes it so much easier to figure out what needs improvements :)
My umbraco gripe
I wasn’t sure where to put this on the forum as there is no roadmap/strategy page so I guess this is the best place.
I have allot of time for Umbraco. Its fast and flexible but there is one gripe that keeps on haunting me. I have ranted about it before and guess what I am going to do it again.
We use the pro licensed version and I was excited to get concierge working, only to find it is slow to the point of timeouts on most reports :-( then my gripe kicked in 'its the database, the database!'. Naively thinking a couple of indexes would solve my issues I fired off performance analyser and was horrified.
To view all Saved log entries using concierge takes about 15 seconds on our development server (using productive data). Now in my case indexes won’t help because under the bonnet of umbraco tiny SQL statements are fired off manny times (almost recursively). DB's have an overhead when executing SQL meaning the less queries the better (yes I know this can be argued..). Whilst joins are amongst most costly operations in a db, a db can do joins allot better that developers can do in code. Partly due to the lack of joins to report a log containing 6000 page saves concierge feels the need to fire off 30,000 SQL transactions (no that is not a typo). This is what takes 15 seconds. The problem is not Concierge it’s the API Concierge uses in other words the guts of the machine.
FYI here is 1 query that gets the same data* in under a second**:
*Same data from what I can tell however there is a lot of stuff going on with versioning that seams irrelevant for the particular ‘Save’ report as the only data returned that can change with versions is the node name and Umb doesn’t version node names.
**There is allot more room for improvement with some much needed schema changes but don’t get me started there..
Yes I am a db guy and not a developer, I don’t have to talk about the object relational mismatch Google has plenty on that. The fact is the backend of umbraco uses a database really badly and that makes me frightened when we think about scalability and longevity.
In the past I have mentioned this and I have had the response 'Umbraco is open source' so get involved :-). That shut me up. Partly because after work and family I can’t find the time to clean the car let alone donate my time to an 'open source' project but also because Umbraco is not really open source. Rather it is free with source code available, for example the rendering engine and the API are licence. There is a small number of core developers (11 actually with 7 active since June 9th) and the code is available so people can help improve it and find bugs but the ownership is firmly private. From what I can tell there is absolutely nothing to stop the project turning closed source and 100% commercial in the future. Perhaps this will never happen but it could, if it did perhaps this would be for the best I don’t know. <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:1; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:variable; mso-font-signature:0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0cm; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} span.EmailStyle15 {mso-style-type:personal; mso-style-noshow:yes; mso-style-unhide:no; mso-ansi-font-size:11.0pt; mso-bidi-font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;} @page Section1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt; mso-header-margin:36.0pt; mso-footer-margin:36.0pt; mso-paper-source:0;} div.Section1 {page:Section1;} --> Now I am guessing I am not the only person who realizes that and that this is the reason whilst although the Umbraco community is steadily growing the number of people actively involved in the core project remains the same.
My last paragraph is off on a tangent so back to my gripe.
The db and how Umbraco uses the db sucks. For me it is the biggest restriction of the system and poses the biggest risk to the project. I have read that Umbraco 5 will use MVP and perhaps this will finally kill my gripe. However until then for me umbraco remains a nice tool for solving simple problems that has an uncertain future.
Jesus the formatting of the above realy screwed up..
Alec: MVPs directly in Umbraco? How do they fit in there? ;)
No seriously, you need to elaborate a bit on your critisism if you want constructive answers. You say the db and how umbraco uses it sucks, I am no db guy so I can't tell if you're right or not, but I do know that there has been discussions about the db because it has some .. hmm.. shortcomings (lack of indexes and such). But if you have the time for it, I encourage you to submit patches or contact the core group and offer your help, rather than just complaining ;)
Hello,
Sorry to break in with a somewhat off-topic question. Alec what software do you use to monitor the SQL transactions and queries that are being executed by Umbraco? I am looking for a tool to optimize an application that uses linq2sql extensively. I know about the SQL Analyzer but I am not really a DB guy and haven't found a good enough reason to invest in it. Therefore I am curious if there might be a cheaper alternative?
Thanks
@Simon - I think Alec means the ASP.NET mvc framework and not MVP. This will potentially "enforce" better practices in data access (maybe using ORM technology like nHibernate with 2 caching layers), possibly making SELECT N+1 scenarios (which I assume the highlighted issue is) easier to pick up while developing.
@Alec - Correct me if I'm wrong, but as I see it Concierge is a Pro-licensed add on, so this probably means that your open source comments are irrelevant. I would however suggest you log this as an issue under your Pro support contract. The issue itself may be in the Umbraco core, but if a commercially supported product is not working, I would suggest it isn't necessarily your place to find the problem. (Although I appreciate that isn't in the spirit of the community Umbraco has).
I've few suggestions to help at this stage, other than ensuring your DB is on same server as the web server to factor out network latency in your high transaction volumes. Maybe enable only shared memory?
Chris: I did understand it, I just had a less serious moment ;)
All
Actually I did mean MVP as in Model-view-presenter not Most Valuable Professional I don’t think our server could handle that. Though I honestly don’t know much about MVC or MVP (I’m not a developer) but I understand the basic concept.
Simon
I could spend quite some time elaborating and perhaps I will some other night but as for getting an 'answer to my question' I didn’t actually ask one it was a gripe post a statement if you wish. I know there are others who share my view and if anything I was hoping to stir them up a little. I don’t really have time but I could be persuaded to get involved though I wouldn’t want to do it alone for the single reason it’s quite a complex task to do correctly. Especially if you get into probable feature creep requests such as versioning of non content stuff like macros and decent membership solution etc. My fear would be that it would take me so long alone that impatient developers would invent additional solutions in parallel and the thing would never be done with. Also such a task would need keen involvm,ent from the application coders who would implement the relevant changes in the application.
bjawnie
I use SQL Server Profiler. It comes with SQL server 2005 (perhaps with express also but I don’t use that)
Chris
MVP/MVC you got it. But you also mention something key in using the phrase "potentially 'enforce' better practices in data access". But not necessarily. As for ORM I am bias but I am not a great fan as the limited experience I have is that the schema of ORM solutions can change quite allot between versions which is not an issue if only one application uses the db. I know Object relational mapping is not perfect but there has to be a balance and being a db guy enforcement of referential integrity and performance should not be left to the application level code and memory cashing.
Yes the open source comments is irrelevant.. sort of. The concierge package it has not lived up to my expectations in more ways than one, it’s a useful tool but it isn’t professionally finished which I can live with from open source but not when you pay for it. My comments about open source where off topic yes, but they where there because I would expect an open source project to be made up of a decent mix of people specialising in various areas application development, testers, documenters db gus n girls but umb appears to be mainly c# guys n girls.
From what I can tell looking at other SQL Server Profiler reports the issue is not with concierge its the umb API/business objects that concierge uses, i.e. the same one as for pro as for the free version of umb. Doing almost any operation in the admin end of umb executes 100's or 1000's of SQL queries when only a handful are really needed. I imagine that this is because some properties only get the data they need when they need it using very granular SQL statements. Because OO can eat up memory objects are destroyed and created with their required child objects on demand resulting in all these SQL entries. MVC should help because as I understand the data access happened in one place for each model and this allow the developer to look at the bigger picture of that the model needs regarding data and when rather that selecting 1000 node name's using a thousand statements one can be used.
Thanks for the suggestion I know it would help but that our architecture though its also no excuse our other much larger highly transactional systems do just fine with the minimal latency we have.
Good night
I'm not going to wage into this other than to say that I do monitor all patches submitted on codeplex (along with other members of the core team).
When deciding if a patch will make it in I look at:
Everyone is welcome to submit patches.
Alec I'm guessing the reason this is happening is due to a leaky abstraction. The API code wraps up all the calls to the DB and returns objects which every one elses code can use free from the worry about SQL statements and schemas. But then used in anger it can cause a mass of SQL statements which seem un-needed. This is the pay off for an easy to use API.
Some queries could/should be optimised but then you risk spreading you db interface around and having loads of one off queries making maintenance and future mods more difficult. Its a fine balance.
A very valid rant - two comments:
1) The way Umbraco uses the DB sucks, but have been improved over the past versions and will be more improved with 4.1. Making a better DB Schema is needed, but would also break all existing installations so it's something that we've wanted to put on hold until v5. It is something that does have the attention from the core's and it's not something we ignore. As it doesn't affect a running site, it hasn't been on the top of the list (ie. the Umbraco runtime doesn't query the db).
2) Quote: "From what I can tell there is absolutely nothing to stop the project turning closed source and 100% commercial in the future.", while this is true it would mean the death of Umbraco and luckily there's no such thing as a retroperspective license, which means that any OSS'ed version of Umbraco would still be OSS and can be improved. Make no mistake, Umbraco will never be closed sourced.
To emphasize the above; any OSS project can change its license as long as it has the permissions to do that, no matter the license. This goes for MIT (Umbraco), GPL or any other license. In the case that the owners decide to change the license it'll only affect any future version of the product and the existing version can then be forked by anyone to continue the project.
And to re-emphasize; We'll never, ever, ever turn Umbraco away from being open source. In fact we'd love to make sure that the UI could be under an open source license as well, we're just waiting for OSI to approve a license that protects branding. The main reason that the UI is not open source is that if it was MIT'ed we'd be under the risk of an "evil", unconstructive commercial fork where companies would take Umbraco re-skin it and package it without us being a little start-up without funding have any chance to defend ourselves. The current license structure was a result of advicing from Martin von Haller Grønbæk one of the leading open source lawyers in Europe. It's done as liberal as possible and hopefully it'll be even more liberal in the (near) future.
Best,
Niels...
slace
Original post is not a patch but I think you know that
Peter
Firstly Excellent article bookmarked!, Secondly 'Its a fine balance' I understand this though would perhaps say that if we can predict certain common behaviours then we can build specific operations for those behaviours. We can have the easy to use APS (with its issues) and a set of robust less granular operations from common workflows.
Niels
Firstly a new schema need not break existing installations if either a) there is a good well tested migration script or b) if a db 'abstraction layer' where made to emulate the old interface. A is probably the easiest to do as b would be a pain in the but involving lots of t-sql and triggers (not to mention the other supported db's).
Thirdly I am happy that this has the attention of the core for v5 and hope there are some good db heads in the group, I would be happy to review the schema (free of charge :-))
lastly I am happy to read you OS statements and have subsequently tattooed them on my forehead :-)
Question about the v5 db (is it going to be from scratch or a series of fixes) either would work but it influences weather I (and hopefully others) can get involved now or not.
And lastly just to follow up on your comments on Concierge:
Very valid points, the slowness in the log-viewer will be solved in the next maintance release so people with more then a 1000 log items can use the viewer as well, without any performance issues. Will put together some more efficient SQL to fetch the log-items (which can then hopefully be merged into the core later) instead of using the current api.
Thanks for posting your issues, makes it so much easier to figure out what needs improvements :)
/Per
is working on a reply...