Anyone know about Cascade events in a relational data base system? How it works, how it helps and if there are any disadvantages. Thanks.
Cascade events are quite simple really. For example, say you have a User table with attribute and primary key username, and an Email table with attributes username and email address. Now it's quite likely that we might make username in Email a reference (foreign key) to username in User, because we want every user that has an email to also be in our User table. Now think about what would happen if you deleted a user in User. Should you delete all the matching rows in Email? If not, what do you do? Some DBMS's will just throw an error, saying something like "You mustn't do that! References exist and we don't know what to do with them!". This is where cascade events come in. If the DMBS supported cascading events, you might be allowed the option to specify whether the DMBS actually throws that error, or maybe delete all the matching (on username in Email) rows, so there are no "dangling" references. This is called a cascade delete.
There are other cascading options too! Another occurs if we try to update username in User to something different. Without cascading options, we would probably throw an error if there are matching rows in Email. But with cascading options, we have the option to automatically update username in Email with the new username. That is called a cascading update.
These are two major ones, but by no means the only existing "cascading" options that exist in some DBMS's.
If it helps, think of "cascading" modifications as "recursive" modifications, as their are synonymous, and is what is meant by "cascading". Modifications "cascade" down to other tables that use the same attribute.
Think about the advantages and disadvantages of this feature. We can now specify exactly what we want to happen when we want to have changes "cascade" to attributes in different tables. A possible disadvantage of allowing these features is that we now have the opportunity to cause modifications on a bigger scale than we might like (depending on design). Changing username in User may cause changes in a different table Email, even if we don't mean to!
Hope this helps.
Related
I'm the QuickBase Admin for my QuickBase app. In the app, there's a dashboard report that's used by individuals with viewer access; that way, they can see their students' data, but can't edit the app, tables, structures, etc.
My app's users want to be able to edit one field with notes on that row's data (each row is a student's data, so they'd want to use that field to add notes on that individual), but viewers don't have editing/data entry access tn any column. Is there a way for users to have editing/data entry access to one field, but not the others?
I know with Tableau and other BI software, this isn't possible, but I wanted to ask since my users asked.
Thank you for reading.
Sure you can.
Actually there are more ways to implement this needs.
My opinion better if you create a new table and make a relationship between the student data and a (new) Notes table and you will be able to setup edit rights eg by record owner.
An other way, you can allow the edit right for your users and you can make a restriction on field level. In this case you have to go through on each field and at the Advanced section you will find Permission - Restrict access by role.
Hopefully you do not have a lot of fields :)
I would like to hear your opinion or how you deal with such cases in practice.
It is about an external person being selected by a user who is already registered in the system.
The information is stored in a staging table for the time being. The internal user expects an answer from the external person, who is unknown to the system.
The external person has two options
Accept
Reject
First case: If the external person accepts, he/she must first make some entries, these should also be stored in the staging table for the time being. However, in order to make these entries, the person must logically register in the system?
Second case: If the external person rejects, it would be superfluous for this person to register in the system.But how can I save and retrieve this answer in order to show it to the internal person?
Does the external person have to register first in order to be able to give an answer (of any kind) so that this answer can be saved and retrieved?
If the person registers in the system, where should personal data be stored, also in a staging table?
I know this answer is very superficial, I am new to development and wonder how temporary user accounts in the system are generally handled in practice.
Translated with www.DeepL.com/Translator (free version)
The way I see it, you'd create a public page (i.e. the one that doesn't require any authentication) and let those "external" people visit it and either accept or reject what's being offered.
Their answer can be stored into a database; I'd suggest you not to create a region which has actual table behind it, but call a stored procedure which will accept certain parameters (external person's answer and possibly some other data) and perform an INSERT operation to the database table.
I am trying to achieve one to many relationship. I know how to do basic one to many relationship between requestor id and userid.
My question is How to refer gtlUserId(resourceRequestTable) to gtlUserId (User table) as by default spring is mapping gtlUserId (resourceRequestTable) to userId in user table
It has some Ways.
I think you should give a specific way during all project !
As My experience each many to one must be a Drop Down in Client side .
However in your Table ResourceTypeEntity should be drop down inside ResourceRequesTable when value of option is Id[primary Key].
Also Your table not seems good design why two many to one map to same table? it may cause 3NF problem in DB also pay attention Cascade it when Parent Table related to other Parent is not good Design ,Keep it simple with uni Direction Many to One And force user to delete manually parent is better ,CaseCade Delete when Parent has related to other table will make exception handling and testing too hard.
please take a look https://examples.javacodegeeks.com/enterprise-java/spring/mvc/spring-mvc-dropdown-box-example/
Background: http://jeffkemponoracle.com/2011/03/11/handling-unique-constraint-violations-by-hibernate
Our table is:
BOND_PAYMENTS (BOND_PAYMENT_ID, BOND_NUMBER, PAYMENT_ID)
There is a Primary key constraint on BOND_PAYMENT_ID, and a Unique constraint on (BOND_NUMBER, PAYMENT_ID).
The application uses Hibernate, and allows a user to view all the Payments linked to a particular Bond; and it allows them to create new links, and delete existing links. Once they’ve made all their desired changes on the page, they hit “Save”, and Hibernate does its magic to run the required SQL on the database. Apparently, Hibernate works out which records need to be deleted, which need to be inserted, and leaves the rest untouched. Unfortunately, it does the INSERTs first, then it does the DELETEs.
If the user deletes a link to a payment, then changes their mind and re-inserts a link to the same payment, Hibernate quite happily tries to insert it then delete it. Since these inserts/deletes are running as separate SQL statements, Oracle validates the constraint immediately on the first insert and issues ORA-00001 unique constraint violated.
We know of only two options:
Make the constraint deferrable
Remove the unique constraint
Option 2 is not very palatable, because the constraint provides excellent protection from nasty application bugs that might allow inconsistent data to be saved. We went with option 1.
ALTER TABLE bond_payments ADD
CONSTRAINT bond_payment_uk UNIQUE (bond_number, payment_id)
DEFERRABLE INITIALLY DEFERRED;
The downside is that the index created to police this constraint is now a non-unique index, so may be somewhat less efficient for queries. We have decided this is not as great a detriment for this particular case. Another downside (advised by Gary) is that it may suffer from a particular Oracle bug - although I believe we will be immune (at least, mostly) due to the way the application works.
Are there any other options we should consider?
From the problem you described, it's not clear if you have an entity BondPayment or if you have a Bond linked directly to a Payment. For now, I suppose you have the link between Payment and Bond through BondPayment. In this case, Hibernate is doing the right thing, and you'll need to add some logic in your app to retrieve the link and remove it (or change it). Something like this:
bond.getBondPayment().setPayment(newPayment);
You are probably doing something like this:
BondPayment bondPayment = new BondPayment();
bondPayment.setPayment(newPayment);
bondPayment.setBond(bond);
bond.setBondPayment(bondPayment);
In the first case, the BondPayment.id is kept, and you are just changing the payment for it. In the second case, it's a brand new BondPayment, and it will conflict with an existing record in the database.
I said that Hibernate is doing the right thing because it threats BondPayment as a "regular" entity, whose lifecycle is defined by your app. It's the same as having a User with a unique constraint on login, and you are trying to insert a second record with a duplicate login. Hibernate will accept (it doesn't knows if the login exists in the database) and your database will refuse.
What is the best strategy for applications that autosave an email before it is sent or save a blog post before it's finished or officially saved? Would it be best to use a separate table in the database for temporary drafts or to have a status column that marks a post as draft or published? I'm not looking for code, just methods, but any other related advice would be welcome as well, like how often to save, etc.
Considering that separate tables for drafts and published articles would be essentially duplicates of each other, I would lean towards just one table with a status column to differentiate between the two.
I do drafting on the Wikipedia way: I save the first version, and all modification's saved (based on time or explicit user command) as a next version. After ie. publication you can delete the draft-graph - or not.
If you save data in database I think it's good to use the same table (you can avoid schema conflicts), and use version/status to track drafts lifecycle.
this applies to more than emails...
I changed my mind on this one. The best way is to use a is_draft column in your table and store both drafts and valid entities in the same table. this has the advantage of the entity keeping the same id even if it switches in and out of draft state (you might want to edit it after you save it, but temporarily remove a required value). it would be confusing for users if they were collaborating on the same document and the id kept changing, amirite?
you would use is_draft=1 to turn off ORM validation rules, trigger validations or check constraints to allow an invalid object to save. yes, you'd likely have to allow nullable fields in your table.
process:
try to save object. validation fails. set is_draft=1 and try to save again. it saves. put big "DRAFT" on the screen somewhere :)
user fills in required info. try to save object. validation passes. set is_draft=0. it saves.
now, regarding email and blog posts, your server shouldn't try to send it or post it right away unless the user hits the save/post button, but that is a different issue really.
OLD ANSWER
The problem is that a draft might not be valid, and cannot be saved in the actual table. For example, say your table demands that the subject be not null, but the user hasn't filled it in yet.
One way would be to have a draft table, and store a serialized version of the entity (and its children) to it. php's serialize() would be something to use, or you could use json. when it is finally valid, the system would save instead to the email (or whatever) table, and delete the draft:
pseudo sql:
create table draft
id int primary key auto increment,
entity varchar(64) not null comment 'this way you can find all drafts of say type Email',
contents longblob not null,
modified timestamp comment 'this way you can sort by newer drafts'
modified_by int not null foreign key to user.id comment 'this way you can filter by the user\'s drafts'
you could also consider a draft_file table for storing attachments or photos for the draft, and be able to access them individually:
create table draft_file
id int primary key auto increment,
draft_id int not null foreign key to draft.id on delete cascade,
size int not null comment 'bytes',
mime_type varchar(64) not null,
file_name varchar(255) not null,
contents longblob,
thumbnail blob comment 'this could be an icon for files/documents'
so, a user starts composing an email, maybe just types in the body, and adds some attachments. your gui saves the email to drafts, and uploads the attachments, saves them to draft_file, and returns the draft id, and the download urls for the files which you display in your gui.
he types in the Subject (To is still blank). Your gui saves the email to drafts, updating the draft table by id, as it knows its id from the previous step.
your users fills in the To field, and hits Send. Your server saves the email to the email table, copies the attachments from draft_file to the email_attachment table, and deletes the draft, preferably within a transaction.
this allows for long-term drafts, gmail-style attachment uploads, while maintaining integrity of your real entity table.