tag:blogger.com,1999:blog-8884584404576003487.post6507201359353139200..comments2024-02-29T09:43:12.251-05:00Comments on ORACLENERD: %ROWTYPE, Part IIoraclenerdhttp://www.blogger.com/profile/12412013306950057961noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-8884584404576003487.post-4287321838862061342009-08-16T20:40:19.468-04:002009-08-16T20:40:19.468-04:00re: "constructor"
Obviously PL/SQL reco...re: "constructor"<br /><br />Obviously PL/SQL record types don't have the OO feature of a constructor, but you can easily mimic that with a function that returns that record type.<br /><br />That function could be overloaded as needed. That function could be more flexible and more transparent to the code that is using it than some DEFAULT values that are tricky to troubleshoot.<br /><br />DEFAULT values in your DDL are generally a bad idea and should be considered suspect upon any review.Clever Idea Widgetryhttps://www.blogger.com/profile/11224068405843575576noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-14485174119089991832009-08-13T14:48:27.037-04:002009-08-13T14:48:27.037-04:00@cristaunit
could you explain what you mean by a ...@cristaunit<br /><br />could you explain what you mean by a "constructor?" I'm not sure I follow (may be just a difference in language).<br /><br />I do consider the fact that I am binding this to the table definition and to change it requires DDL...I typically use it (DEFAULT values) on yes/no or on/off columns or those that have a lookup table (with the NOT NULL, FK constraints). Not necessarily items that would be exposed to the application.<br /><br />chetoraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-48844138975782609952009-08-12T13:44:49.101-04:002009-08-12T13:44:49.101-04:00also: they are OK for sys_guid() on raw(16) column...also: they are OK for sys_guid() on raw(16) columns - because that is occasionally something very useful and the opaque pitfall is avoided if the column has NOT NULL and UNIQUE constraints.Clever Idea Widgetryhttps://www.blogger.com/profile/11224068405843575576noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-83401056137958931302009-08-12T13:42:50.779-04:002009-08-12T13:42:50.779-04:00I'm not a big fan of DEFAULT in table definiti...I'm not a big fan of DEFAULT in table definitions anyway. Maybe they are OK for a timestamp column that is intended to be hidden from application usage anyway.<br /><br />But when you are talking about default values for a record variable, you should be creating a "constructor" function that does that instead.<br /><br />The risk of using DEFAULTs in your DDL is that the binding between their existence and your DML code is extremely opaque and a recipe for failure over time.Clever Idea Widgetryhttps://www.blogger.com/profile/11224068405843575576noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-76745299394133965912009-08-11T21:19:30.404-04:002009-08-11T21:19:30.404-04:00@noons
That is too bad, as it might make life a b...@noons<br /><br />That is too bad, as it might make life a bit easier.<br /><br />I don't think it will be a method I use in the future, but for this particular "clean-up" project, it's a good "first-pass" solution (as I don't know all the rules yet).oraclenerdhttps://www.blogger.com/profile/12412013306950057961noreply@blogger.comtag:blogger.com,1999:blog-8884584404576003487.post-18852567301147780772009-08-11T21:17:24.497-04:002009-08-11T21:17:24.497-04:00The *theory* behind using %ROWTYPE is that if your...The *theory* behind using %ROWTYPE is that if your table defines column status as VARCHAR2(1)and later on you do<br /><br />ALTER TABLE my_table MODIFY status varchar2(10);<br /><br />you then don't need to chase the PL/SQL code declarations of STATUS and change them as it will "know" it has changed length.<br /><br />But as you well note, it has some short-comings as well: the constraints are not exactly propagated the same way...Noonshttps://www.blogger.com/profile/07694829378563989648noreply@blogger.com