I have a table with a trigger that points to an assembly:
CREATE TRIGGER [dbo].[triggername] ON [dbo].[tablename]
WITH EXECUTE AS CALLER
AFTER DELETE, UPDATE
NOT FOR REPLICATION
AS EXTERNAL NAME [Namofassembly].[blahblah].[blahblah]
We also using code first EF in .net 4.
When I use delete everything works fine but the trigger does not get called.
dataRepo.UsersPermanentAuditAssignments.Remove(isInsertFound)
When I use update I get a permissions error. This is either when I try it through the object model or a dataRepo.Database.ExecuteSqlCommand(updateSql)
System.Data.SqlClient.SqlException: The context transaction which was active before entering user defined routine, trigger or aggregate "name" has been ended inside of it, which is not allowed. Change application logic to enforce strict transaction nesting.
Everything works fine when I run the queries via the sql management studio.
I also am not able to change this configuration so while I don't care for this design I am not able to change it.
My questions are:
1> Why would the delete not get logged but work?
2> Do I need to add something extra to my repo configuration object that will allow this to work? Do I need to add some transaction like unitofwork before I start this since it has a trigger maybe?
I have figured out the causes of this issue.
It relates to having a composite primary key (station,user) and trying to update one of the values.
I could not update any column of the primary key, ie change the user assigned to a station.
The trigger failure masked the issue of not being able to update a value inside the key.
My experiments show the following for the compositekey/pk update:
Method History Trigger Result
EF.SaveChanges Enabled Fail at trigger
EF.SaveChanges Disabled Fail at trigger
EF.ExecuteSQLCommand(sql) Enabled Fail at trigger
EF.ExecuteSQLCommand(sql) Disabled Works
Unfortunately, I don't have the ability to change to a surrogate with a unique index which would work. Also, the trigger CLR prevents me from using DataBase.ExecuteSQLCommand(sql) also which I believe is actually a problem with the CLR of which I have not ability to modify.
So my advise (that I can't take) is if you get this use a surrogate key and a unique index instead of combining the 2.
If anyone knows any way to allow EF to allow you to change a value inside a composite/primary key please comment.
Related
I have a problem that i need to solve using DATANUCLEUS (JDO), maybe a limitation of something that was not covered by JDO specs.
I need to catch when objects are loaded in a Query - there is NO InstanceLifecycleListener for this! (Queried objects should be treated as LOADED objects after all - they can be changed, detached, etc)
Query query=pm.newQuery(...);
Collection col=(Collection)query.execute();
Another way to do it would be to catch when objects are made TRANSIENT. I found no way of doing that either!
pm.makeTransientAll(col,true);
Any ideas?
For detached Query elements, i use the DetachLifecycleListener over the PMF, that listens to the DETACH method. That's the only way I've found to make InstanceLifecycleListener work on queries.
Here's what i found out with a lot of DEBUG:
1) Queries DO NOT trigger any InstanceLifecycleListener (except when elements are DETACHED) if the DEFAULT fetch group (aka METADATA default-fetch-group) is REMOVED from the PersistentManager prior to the query. In other words: one cannot use the pm.getFetchPlan().clearGroups() method, or one has to ADD the DEFAULT fetch group back before executing the query. SO... if there is a need to define a programmatic fetch group, it needs to take into account that the DEFAULT fetch group will (must!) be present (aka, all the fields defined in the metadata!) for the InstanceLifecycleListener to work.
The workaround would be to DEFINE the DEFAULT fetch group with ONLY the KEY (it's needed) and just change the logic to work with that. What i did exactly... The result?
2) the getObjectById method STOPS triggering the postLoad!!! After debug i found that for this to work, the DEFAULT fetch plan MUST define another field apart from the KEY one!
There is a total lack of information about the way the FETCH GROUPS affect the way the InstanceLifecycleListener are triggered, and Apache JDO (at least) should revise the way this works (or at least the DOCS), so that JDO users don't go nuts with implementation.
I have an app using React + Redux and coupled with Firebase for the backend.
Often times, I will want to add some new attributes to existing objects.
When doing so, existing objects won't get the attribute until they're modified with the new version of the app that handles those new attributes.
For example, let's say I have a /categories/ node, in there I've got objects such as this :
{
name: "Medical"
}
Now let's say I want to add an icon field with a default of "
Is it possible to update all categories at once so that field always exists with the default value?
Or do you handle this in the client code?
Right now I'm always testing the values to see if they're here or not, but it doesn't seem like a very good way to go about it. I'd like to have one place to define defaults.
It seems like having classes for each object type would be interesting but I'm not sure how to go about this in Redux.
Do you just use the reducer to turn all categories into class instances when you fetch them for example? I'm worried this would be heavy performance wise.
Any write operation to the Firebase Database requires that you know the exact path to the node that you're writing.
There is no built-in operation to bulk update nodes with a path that is only partially known.
You can either keep your client-side code robust enough to handle the missing properties, or you can indeed run a migration script to add the new property to each relevant node. But since that script will have to know the exact path of each node to write, it will likely first have to read/query the database to determine those paths. Depending on the number of items to update, it could possibly use multi-location updates after that to update multiple nodes in one call. E.g.
firebase.database().ref("categories").update({
"idOfMedicalCategory/icon": "newIconForMedical",
"idOfCommercialCategory/icon": "newIconForCommercial"
"idOfTechCategory/icon": "newIconForTech"
})
I need a help for while creating the collection the below error is came in server console.How to solve the error ?
Error:
Warning: creating anonymous collection. It will not be saved or synchronized over the network. (Pass null for the collection name to turn off this warning.)
TLDR: you need to provide a collection name as an argument when you create a shared collection.
In most cases, you want to provide a name as a parameter when you define a collection:
Docs = new Meteor.Collection('docs');
When you don't, you create anonymous collection:
Items = new Meteor.Collection();
In the first case, the collection is shared and synchronized between client and server, and the name you've provided is used as a table name in order to store the collection in Mongo.
Anonymous collections are local in the place they've been created. Their contents are never synchronized. Therefore, even if you create such collection in a piece of code that will be run on the server and on the client, those two collections will be separate things: data created on the server won't be visible on client, data created on the client won't be visible on server, and both won't be stored in the database.
There are legitimate use cases for anonymous collections, mostly on the client side when you need to create some temporary data, but want to retain all the benefits of Minimongo and reactivity. However, it's one of those things that are needed rarely and you really do know when you need to do it. It's more probable that a beginner made a mistake and forget to provide the collection name when he wanted to create a typical shared collection. Therefore, the system issues a warning to make sure that you really wanted to do what you just did.
Therefore:
If your goal was to create an anonymous collection, and you know what you're doing, don't worry about that message. It's just a warning, the code will be functional and do what it's told to.
If you wanted to create a normal collection, or are just starting out and don't know what's this all about, just add a parameter to your collection definition.
In the controllers generated by Visual Studio, as well as the sample application (ContosoUniversity), the Index action always has something like
var departments = db.Departments.Include(d => d.Administrator);
What's the difference between that and
var departments = db.Departments;
First I suspected that the first one (with Include) enables the view to retrieve department.Administrator. But the second one (without Include) seems to be able to do that as well.
The Include tells Entity Framework work to eagerly load the Administrator for each Department in the results. In this case, Entity Framework can use a SQL join to grab the data from both tables in a single request.
The code will still work without the Include, but the first time you access a Department's Administrator, EF will need to hit the database to load it (since it wasn't pre-loaded). Loading data on demand (lazily) is a nice feature but it can be a serious performance problem (known as an N+1 problem). Especially if you are accessing the Administrator for each Department (for example, in a loop) - instead of one database call, you will end up with many!
In first case (with Include) when you write department.Administrator servers the object from memory that has been eagerly loaded due to Include method. In the second case, an sql statement will be executed to fetch the Administrator record from the db for each department object.
See the "Lazy, Eager, and Explicit Loading of Related Data" section in this tutorial:
http://www.asp.net/entity-framework/tutorials/reading-related-data-with-the-entity-framework-in-an-asp-net-mvc-application
var departments = db.Departments;
This will retrieves the aggregate domains only if LazyLoadingEnabled is enabled & MultipleActiveResultSets is set to true in connection string.
In asp.net (using MVC, but this happens in regular too)
Profile.GetProfile(username);
will update the LastActivityDate for that user. This is not intended when someone else is viewing that user's profile.
In the membership class you can specify whether to update this date with a second param, like so:
Membership.GetUser(username, false); // doesn't update LastActivityDate
Membership.GetUser(username, true); // updates LastActivityDate
Is there anyway to do something similar in the Profile provider without writing my own provider?
You might use one ugly workaround which includes changing aspnet_Profile_GetProperties stored procedure. This one is responsible for getting the properties while accessing user profile.
Open this procedure and you will find following code at the bottom:
IF (##ROWCOUNT > 0)
BEGIN
UPDATE dbo.aspnet_Users
SET LastActivityDate=#CurrentTimeUtc
WHERE UserId = #UserId
END
Remove it in order to stop updating the LastActivityDate. You will still get LastActivityDate updated when calling Membership.GetUser(username, true);.
You might look at using a provider that someone else has written, rather than write your own.
This one on Scott Guthrie's blog includes stored procedures which could be called directly by your own code to get the information:
http://weblogs.asp.net/scottgu/archive/2006/01/10/435038.aspx
This page has an msi download which installs a sample application for working with custom Profile data. The table based profile performs a lot better than the default on, where all of the profile data is contained in a single database field. The table based one is also a lot easier to query directly, which will help you with your question. The stored procedure from the sample schema is called getCustomProfileData
Otherwise, just query the database directly.