Hello I am completely newbie in Documentum but using DQL for some data extraction purpose.
In dm_relation I have a relation which contains parent_id & child_id which are r_object_ids of 2 types(tables for me)
I am facing a problem. It would be clear if you can tell me that can a record exist in the relation even if the record is deleted in the child table(type)?
I hope I am clear. Also I suppose for now that a record cannot exist in the relation if parent record is deleted (which contains the parent_id).
Thanks.
I think it depends on the properties of the relation. A similar question has been asked here: https://community.emc.com/message/591116#591116
Related
I have several entities with several relations. They have one "starting" entity. When I want to persist data to my database, I set the data to each entity (implicitly with a method I wrote, because I import that data from an xml), but only persist and flush the main entity. I used cascade:persist in the entities accordingly. And all that works just fine.
But: There are entities (the OneToMany side) that should check in the database, whether or not the record already exists and only set a new record, if not. And if the record exists the ManyToOne side should get that foreign key, that already exists.
Is there an easy way to tell doctrine to do so on my single persist/flush of the main entity?
edit
Maybe I can simplify the question to:
Is it possible to flush an object and doctrine will check if this record already exists in the database (in one query)? Or do I have to do make a query to check for existing records first and then a second query with my data to be set?
edit end
Thanks a lot for your help
David
I can't believe this hasn't come up for other people, but I'm unable to find a solution.
Let's say I have two entity types, A and B with a one-to-many relationship. A has a collection of Bs.
The form for A has a CollectionType for the Bs, with a custom entry_type for B, allow_add and allow_delete set to true. When the form is created/populated/rendered, the Bs' fields are identified by their index in the collection. When the form is posted back, the fields are mapped back onto the B entities according to the index again.
What if the database in the mean time decided to return the Bs in a different order? Then the values get swapped around on the Bs! I can't have that, as other entities will reference the Bs and now they've changed their meaning!
Even if the database doesn't change the order, the same issue appears when a B is deleted: The fields get shifted through the Bs and a different one deleted! (Ok, I'm not a 100% certain this happens, as there's a gap then in the numbering of the posted fields.) I've found this similar question where it does happen when another one is created (Symfony CollectionType regards deletion+creation as a modification of an item), but that sort of drifted from the issue and there's no usable answer.
How do I make sure the form is updating the entities the user actually edited?
I already tried to render the Bs' IDs as a HiddenType, but then the form rightfully complains that the ID has no setter. It would probably force an ID on the wrong B anyways and Doctrine doesn't like that. I suppose I could add the Bs as unmapped and copy the values over to the correct objects manually, but that would defeat a good chunk of Symfony's form system.
I've used CollectionType before, but not for entities that are referenced elsewhere. I would then delete all of the previous entities and create the collection anew from the posted data. But I can't do that now, can I?
Since doctrine 2.1, it's possible to change how associations are indexed. This will allow you to use the id as the collection key (as the field has to be unique):
#OneToMany(targetEntity="B", mappedBy="A", indexBy="id")
You might also need to enable orphanRemoval so that the data is actually removed instead of the relation just set to null.
I'm having some trouble getting relation deletion to work exactly how I would expect it to.
For example I have two simple tables, users and permissions with a one-to-many relation between users and permissions (or it could be many-to-many in this example as well).
I first tried deleting one of the related permissions using userDatasource.deleteItem() or userDatasource.item.permissions[index]._delete() but when you use either of those functions it marks the record as deleted client side so you run into trouble when you need to insert again.
I then found a related question that said to use item.relation.splice(startIndex, 1) to just break the relation and that worked as expected but now I have a bunch of extra rows in my database with the user foreign key null. I would much rather have the same behavior as .splice but also have it delete those records from the database. Is there any way to do that or is App Maker supposed to detect the broken relation and automatically delete the row from the table?
Just do a check after the splice like this:
if (item.relation.length === 0) {
item._delete();
}
What is the best practice for checking if any references to a particular model record exist before deleting that record? Basically, I have a model that represents images, and all metadata associated with an image. Other models will have references to one or more images (depending on the model).
Let's say for example, I have an "Item" which has a "MainImage" and an "AltImage", both of which are just references to the Image model. If I delete an Item record, I have to check if the two images are referenced by any other Item, or any other table, and if not then delete the Image.
How would I go about this?
Since you are using a database, let it maintain referential integrity using foreign key constraints on the images. The database or EF will prevent you from deleting the image if it is still being referenced. You can catch this exception and continue processing the request without deleting the image.
I found a blog posting Inferring Foreign Key Constraints in EF that may be of use in setting these up.
Couple ideas based on what you prefer:
Create trigger in you DB
That will delete alt img.
and everytime you want to delete the main record row the other record will be deleted too.
Another (based on nhibernate)
Make sure that alternative image in your entity framework might have possibility to cascade commands. And in that case if you delete one image the other one will be deleted too. Here is one example from google how to do this
Most clumsy but easiest is:
Delete both records when you deleting the image.
I've started porting a .NET SQL Server application to LINQ to Entities. I have (among others...) one table called Users, and one called Time. Time is reported on a specific user (UserId), but it is also recorded which user made the report (InsertedByUserId) and possibly who has updated the Time since insert (UpdatedByUserId). This gives me three references to the table Users.
When I generate a .EDMX from this I get three references to the table Users: User, User1 and User2. Without manual edit I have no way of knowing which one refers to the UserId, InsertedByUserId or UpdatedByUserId field.
How do others solve this? Maybe it's not necessary to register ALL references, and stick with InsertedByUserId and UpdatedByUserId as ints?
(The manual edit wouldn't be a problem if the database were never updated, but as we make changes to the database every now and then we occasionally have to regenerate the .EMDX, thus removing all manual changes.)
Thanks in advance!
Jos,
Generally when I make my foreign keys, I name them accordingly. From the Entity designer you can differentiate between the different Navigation Properties (ie User, User1, User2) by looking at the FK association (as long as you named your foreign keys distinctly). For Instance I have a ModifiedById and CreatedById field in each table. Both fields reference my SystemUser table, My foreign keys are named like this: FK_[TableName]_SystemUser_CreatedBy and FK_[TableName]_SystemUser_ModifiedBy.
You should notice that in the Navigation properties you can see the Foreign key. You can also modify the name of the Navigation Property (which is in the Conceptual Side "CSDL portion" of the EDMX), and this change will stay when you update your EDMX from the database.