Hi Siddhartha, here are my answers: First the design of empire DB lets you instantiate most classes yourself thus lets you override methods to extend the functinoality. Hence it is a very traditional object orientated approach.
For business logic I would strongly recommend to create a class for each entity as an extension of DBRecord. Inside DBRecord you can then override many useful methods such as: - getValue() to intercept getting data - setValue() to intercept setting data - validateValue() perform context specific validation logic - modifyValue() intercept modification (later than setValue after validation has already been made) - getFieldOptions() intercept option lists. This is also the place to supply dynamic options like in your question no 3 - isFieldReadOnly() perform context specific checks whether a field is read only or not If you want to intercept the lifecycle of an object (or record) you will have to override methods of your Table definition class (extended from DBTable) like e.g. - initRecord() to intialize a new record - readRecord() to intercept loading a record from the database - updateRecord() to insert or update a record in the database (depending on it's state) - deleteRecord() to delete a record. This should meet most of your requrirements. Regards Rainer > from: Siddhartha Upadhyaya [mailto:[email protected]] > to: Rainer Döbele (JIRA) > re: Re: [jira] [Commented] (EMPIREDB-200) Option to have non- > persistent column in DBTable / DBView > > Hi Rainer, > > I am new to this Empire DB and try to learn the capability it has. First of > all I > will like to thanks to you for your reply which show me the way to achieve my > requirement. > > I have one more question and just want to check with you before I go for any > formal request. Please find those below: > 1. Do we have any business logic validation mechanism for all the setter > operation we perform against the Record ? > > 2. Do we have any callback mechanism for the life cycle of an Object, for > example, when a record get created [not saved in database], when we > modify a record or when we try to save a record. > > 3. This one is related to the Options we have. As per the example I notice the > option is static values. If I want to provide the options against a list of > dynamic values, How I can achieve it ? > > > > > > On Sunday, 24 November 2013 11:02 PM, Rainer Döbele (JIRA) <empire-db- > [email protected]> wrote: > > > [ https://issues.apache.org/jira/browse/EMPIREDB- > 200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=13830991#comment-13830991 ] > > Rainer Döbele commented on EMPIREDB-200: > ---------------------------------------- > > Yes, this one is a bit more tricky. > The question is, why do you need a database column at all, you can simply > add a new property to your DBrecord derived class (you need the logic > anyway), and use the getters and Setters. > But I agree sometimes you need metadata for that as well (like e.g. with our > front-end-Extension like for JSF). > In this case you can define a DBColumnExpr in your table class together with > the other table columns. > However still this would not be a true artifical column as it e.g. won't > appear > in the list of table columns. > In many years I have always been able to avoid this feature - but I must > confess, that many times I had wished is exists before I found out again that > I > can live without. > But for simplicity it's worth considering it again - and weigh the pros and > cons. > Anyone else who has an opinion on this? > > > > > > Option to have non-persistent column in DBTable / DBView > > -------------------------------------------------------- > > > > Key: EMPIREDB-200 > > URL: https://issues.apache.org/jira/browse/EMPIREDB-200 > > Project: Empire-DB > > Issue Type: New Feature > > Components: Core > > Affects Versions: empire-db-2.4.2 > > Reporter: Siddhartha Upadhyaya > > > > Option to have non-persistent column in DBTable / DBView. > > We should have option to add a column / attribute for DBTable / DBView, > which is non-persistent in nature. So, the value of the Column / attribute > will > not be stored in the Database, but it will be available as part of the Java > Object to the application. The value of the column / attribute will be depend > on the business logic. > > If we consider DBRecord is the Java Bean in an business layer. we may need > to store some of the calculated data. This option will have us to do it. > > > > -- > This message was sent by Atlassian JIRA > (v6.1#6144)
