I'm using the SubSonic scaffold control with auto-generating many to many controls.
<subsonic:Scaffold ID="scfMain" runat="server"
AutoGenerateManyToMany="true"></subsonic:Scaffold>
On Page_Load I'm setting the table name
scfMain.TableName = "Foo";
The many to many controls are generated by a many to many table, two foreign keys, two primary keys. This works initially, but after a while the many to many controls disappear. The only way to get them back is to restart the app somehow, either by changing the web config, recycling the app pool, or restarting the site.
Is this a known bug, or is there something I'm doing wrong? I'm seeing the same thing on my local machine, staging, and production, so it doesn't seem to be unique to one environment.
The many to many controls are generated by a many to many table, two foreign keys, two primary keys
Does that mean you have two primary keys in your many to many table? SubSonic does not support multiple primary keys in one table.
Related
I have created an angular application in which data are being shown in a table. An user can update the entry in table cell. What I want is, sync among different browser tabs as well as different browsers for multiple users. As an user updates a value, it should get updated everywhere. Suggest some way to achieve this.
In tabs, you can take a look to Webstorage (localStorage is implemented in all modern browsers), but in browsers I think that it's impossible or at least, it has not an inmmediate solution...
I'm working on a distributed system that uses CQRS and DDD principles. Based on that I decided that the primary keys of my entities should be guids, which are generated by my domain (and not by the database).
I have been reading about guids as primary keys. However, it seems that some of the best practices are not valid anymore if applied to Azure SQL database.
Sequential guids are nice if you use an on premise SQL server machine - the sequential guids that are generated will always be unique. However, on Azure, this is not the case anymore. As discussed in this thread, it's not even supported anymore; and generating them is also a bad idea as it becomes a single point of failure and it will not be guaranteed unique anymore across servers. I guess sequential guids don't make sense on Azure, so I should stick to regular guids. Is this correct?
Columns of type Guid are bad candidates for clustering. But this article states that this is not the case on Azure, and this one suggests the opposite! Which one should I believe? Should I just make my primary key a guid and leave it clustered (as it is the default for primary keys); or should I not make it clustered and choose another column for clustering?
Thanks for any insight!
the sequential guids that are generated will always be unique.
However, on Azure, this is not the case anymore.
Have a look at the bottom of this post here - http://blogs.msdn.com/b/sqlazure/archive/2010/05/05/10007304.aspx
The issue with Guid's (which rely on NEWID()) is that they will be randomly distributed which has performance issues when it comes to applying a clustered index to them.
What I'd suggest is that you use a GUID for your Primary Key. Then remove the default clustered index from that column. Apply the Clustered Index to some other field on your table (i.e. the created date) so that the records will be sequentially/contiguously indexed as they are created. And then apply a non-clustered index to your PK Guid Column.
Chances are, that will be fine from a *SELECT * FROM TABLE WHERE Id = " point of view for returning single instances.
Similarly, if you're returning lists or ranges of records for display in a list, if you specifiy the default order by CreatedDate, your clustered index will work for that
Considering the following
Sql Azure requires a clustered index to perform replication. Note, the index does not have to be unique. http://blogs.msdn.com/b/sqlazure/archive/2010/05/12/10011257.aspx
The advantage of a clustered index is that range queries on the index are performed optimally with minimum seeks.
The disadvantages of a clustered index is that, if data is added in out of sequence order, page split may occur and inserts may be relatively slower.
Referencing the above, I suggest the following
If you have a real key range you need to query upon, for example date, sequential number etc
create a (unique/non-unique) clustered index for that key.
create an additional unique index with domain generated GUIDs.
If no real key range exists, just create the clustered unique index with domain generated GUIDs. (The overheads of adding a fake unneeded clustered index would be more of a hindrance than a help.)
As you can see from the image i have a one-to-many relation ship between these two tables. BUT i want to make it soo its a Many-to-many. Im using AssetID as the key for these relationships.
Any ideas on how i could create this??
The reason whu need it as a Many-to-Many as im using this in powerview and using Column headers as sliders. An example of this would be if i was to select Windows 7 in the tblOperatingSystem slider the slider which i use for tblAssets would only display what is relevant to windows 7, where as i want to be able to do the opposite and select in tblAssets silder and only the OS would appear which is relevant in the tblOperatingSystem slider
I have already Tried to create a new table which just has AssetID and then connect tblAssets and tblOperatingSystem to it but this method doesnt work for the sliders.
Any ideas round this?
If I'm understanding the issue correctly, this is down to a limitation of PowerPivot (and the SSAS tabular model) in which it is unable to properly model many-to-many relationships. The relationship can be enforced in one direction (as you can see in your OS slider), but doesn't work on the other direction.
A way I've managed to work around this in PowerPivot/PowerView in the past is to create an additional, de-normalised table, which contains all possible combinations of OS and Asset, with a new identity column (or a concatenation of OSID and AssetID) as a Key. Configure the one-to-many relationships to tblOperatingSystem and tblAsset as required.
The critical part to this, is to include your data columns here also, using DAX functions to populate the values. You can then use this new de-normalised table as the source for both of your sliders (and hide the originals from the client), which will automatically filter each other when one is selected.
Now, it's not terribly efficient as there's a lot of duplication, so if anyone else can suggest another way to achieve this, I'd be interested to hear it myself! Just beware of using this with really large data models, as it can slow things down a lot.
Alternatively, I came across this article (which contains good links to similar posts by Marco Russo and Alberto Ferrari) but I haven't tried it out, so I'm not sure how well it plays with PowerView, since both source articles pre-date PV.
PowerPivot doesn't support many-to-many relationship modeling nativly but you can emulate it using DAX. All you need to do is in you measure list the related many-to-many tables in your calculate statment. For example (from http://gbrueckl.wordpress.com/2012/05/08/resolving-many-to-many-relationships-leveraging-dax-cross-table-filtering/) given a layout like:
Then to write a measure on the Audience table that counts the number of rows but takes into account the filtering on the Targets table you would write:
RowCount_M2M:=CALCULATE(
[RowCount],
'Individuals',
'TargetsForIndividuals',
'Targets')
By listing the other tables their filter contexts will overlap and you get the joining you are looking for.
I know this question has been asked a million times, but I can't seem to find one that really gives me a good understanding of how relationships work in Kohana's ORM Module.
I have a database with 5 tables:
approved_submissions
-submission_id
-contents
favorites
-user_id
-submission_id
ratings
-user_id
-submission_id
-rating
users
-user_id
votes
-user_id
-submission_id
-vote
Right now, favorites,ratings, and votes have a Primary Key that consists of every column in the table, so as to prevent a user favoriting the same submission_id multiple times, a user voting on the same submission_id multiple times etc. I also believe these fields are set up using foreign keys that reference approved_submissions and users so as to prevent invalid data existing in the respective fields.
Using the DB module, I can access and update these tables no problem. I really feel as though ORM may offer a more powerful and accessible way to accomplish the same things using less code.
Can you demonstrate how I might update a user voting on a submission_id? A user removing a favorite submission_id? A user changing their rating on a particular submission_id?
Also, do I need to make changes to my database structure or is it okay the way it is?
You're probably looking for has_many_through relationships.
So to add a new submission, you'd do something like
$user->add('submissions', $submission);
and to remove
$user->remove('submissions', $submission);
You may want to consider restructuring your database table and key names so you don't end up doing a lot of configuration.
I have a few large forms that I need to provide visual cues about the before/after state, so the person approving the form can see what has been modified (not the previous answer, tho that would be a plus). This is currently being done with an extra column for each column of data (Name, Name_IsModified, Phone, Phone_IsModified, etc...). I'm curious if there was a better way to getting around this, leveraging SubSonic?
The initial load is done by grabbing data from 6 source tables on 3 different servers. This data is saved in the form tables, where it resides until it is approved by various people who will manually update it into the live systems that then update the 6 source tables. The visual cues are primarily used during the approval process, but are occassionaly used to research when a change has been made in the past.
Since I have to make a bunch of updates, I thought this might be a good time to break away from the legacy 2000+ lines of code, making my job a bit easier!!!
Thanks,
Zach
All of the properties on SubSonic objects are actually collections and you can pull this out and review changes - all without reflection.
We have a "DirtyColumns" collection (not sure if it's public or not) that we use to run updates - this would be the thing you'd want to have a look at.