| org.kuali.module.chart.dao.FiscalYearMakersDao
All known Subclasses: org.kuali.module.chart.dao.ojb.FiscalYearMakersDaoOjb,
FiscalYearMakersDao | public interface FiscalYearMakersDao (Code) | | |
Method Summary | |
public void | deleteNewYearRows(Integer requestYear) when the reference objects for a base fiscal period are copied into the next fiscal period, there is an option to delete all
of the next period objects that already exit and replace them with their base period counterparts this method reads a list of
the delete order which satisfies RI (i.e., the dependent object must be deleted before the parent object) and does the job in
the proper order. | public void | deleteYearAfterNewYearRowsForParents(Integer requestYear, Class childClass) | public Integer | fiscalYearFromToday() This method... | public HashMap<String, ArrayList<Class>> | getChildParentMap() | public HashMap<String, Class> | getMakerObjectsList() | public boolean | isAParentOf(String testClassName, Class childClass) | public void | makeUniversityDate(GregorianCalendar newYearStartDate) this is the only routine that simply replaces what is there, if anything but, we have to do a delete--otherwise, we can get
an optimistic locking exception when we try to store a new row on top of something already in the database. | public void | resetCascades() auto-update or auto-delete in OJB will interfere with the copy order prescribed above. | public void | setChildParentArrayMap(HashMap<String, Class[]> childParentArrayMap) This method... | public void | setLaggingCopyCycle(HashSet<String> laggingCopyCycle) the "lagging copy cycle" objects are those which are always one fiscal period behind. | public void | setMakerObjectsList(HashMap<String, Class> makerObjectList) This method... | public LinkedHashMap<String, FiscalYearMakersCopyAction> | setUpRun(Integer baseYear, boolean replaceMode) | public void | testRIRelationships() | public void | testUpdateTwoDigitYear() |
replaceMode | final public static boolean replaceMode(Code) | | |
deleteNewYearRows | public void deleteNewYearRows(Integer requestYear)(Code) | | when the reference objects for a base fiscal period are copied into the next fiscal period, there is an option to delete all
of the next period objects that already exit and replace them with their base period counterparts this method reads a list of
the delete order which satisfies RI (i.e., the dependent object must be deleted before the parent object) and does the job in
the proper order. This method...
Parameters: RequestYear - |
deleteYearAfterNewYearRowsForParents | public void deleteYearAfterNewYearRowsForParents(Integer requestYear, Class childClass)(Code) | | when we want to copy two years at a time for some tables, we use this method with "slash and burn" mode to delete any rows
for the year after RequestYear that already exist for the parents
Parameters: RequestYear - Parameters: childClass - |
fiscalYearFromToday | public Integer fiscalYearFromToday()(Code) | | This method...
|
getChildParentMap | public HashMap<String, ArrayList<Class>> getChildParentMap()(Code) | | fetch and set a map of child classes involved in fiscal year makers and a list of their RI parents
|
getMakerObjectsList | public HashMap<String, Class> getMakerObjectsList()(Code) | | fetch and set a map of child classes involved in fiscal year makers (ALL such classes should be included, even those which
have no parent(s) in the RI tree.)
HashMap containing the |
isAParentOf | public boolean isAParentOf(String testClassName, Class childClass)(Code) | | This method checks to see whether the test class is in the parent list for the child class
Parameters: testClassName - Parameters: childClass - true if testClassName is a parent class of childClass |
makeUniversityDate | public void makeUniversityDate(GregorianCalendar newYearStartDate)(Code) | | this is the only routine that simply replaces what is there, if anything but, we have to do a delete--otherwise, we can get
an optimistic locking exception when we try to store a new row on top of something already in the database. we will delete by
fiscal year. the accounting period is assumed to correspond to the month, with the month of the start date being the first
period and the month of the last day of the fiscal year being the twelfth. the fiscal year tag is always the year of the
ending date of the fiscal year
Parameters: newYearStartDate - |
resetCascades | public void resetCascades()(Code) | | auto-update or auto-delete in OJB will interfere with the copy order prescribed above. (Tables A and C may be a parents of
Table B, but A may have no relation to C. If A has an auto-xxx on B, then B will be written when A is, even if C is later in
the copy order than A, and an RI exception will result.) So, the code resets any auto-xxx properties on tables involved in a
fiscal-year-makers parent-child relationship. this routine resets the original values at the end of fiscal year makers
|
setChildParentArrayMap | public void setChildParentArrayMap(HashMap<String, Class[]> childParentArrayMap)(Code) | | This method...
Parameters: childParentArrayMap - |
setLaggingCopyCycle | public void setLaggingCopyCycle(HashSet<String> laggingCopyCycle)(Code) | | the "lagging copy cycle" objects are those which are always one fiscal period behind. in other words, the base period for the
other objects (the source period for the copy) is the request period for them (the target period for their copy). This
method...
Parameters: laggingCopyCycle - |
setMakerObjectsList | public void setMakerObjectsList(HashMap<String, Class> makerObjectList)(Code) | | This method...
Parameters: makerObjectList - |
setUpRun | public LinkedHashMap<String, FiscalYearMakersCopyAction> setUpRun(Integer baseYear, boolean replaceMode)(Code) | | this returns the data structure containing a copy order that is consistent with the RI relationships configured in the XML
Parameters: baseYear - Parameters: replaceMode - |
testUpdateTwoDigitYear | public void testUpdateTwoDigitYear()(Code) | | |
|
|