OFBiz › OFBiz - User

Help regarding migration services

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Swapnil Sawant

Help regarding migration services

Hi,

I have following queries while writing migration service/s :

1. I have created two new rows in an existing entity. In this case, only exporting data to XML should be done ?

2. Functionality which I have implemented won't work with old data. In that case, how migration process should be carried out ?

For example :

- In my implementation, I am tracking leave applications against leave balance (i.e. before creating a leave application ,his/her current balance would be checked)

- When an already approved leave is rejected, corresponding 'no of leaves'(calculated using a service) gets credited back to his/her balance

- But,as per old data, there wont be any (stored) value for 'no of leaves'.

- If at all I use above service (for calculating no of leaves from existing dates),it will give rise to inconsistency of data because 'calculated no of leaves' would not be calculated against some 'leave balance'

Please guide me in this context.

Thanks & Regards,

Swapnil Sawant

________________________________
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________

Jacques Le Roux

Re: Help regarding migration services

Administrator

Quick answer: this may help (examples)
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration

Jacques

Swapnil Sawant wrote:

> Hi,
>
> I have following queries while writing migration service/s :
>
>
> 1. I have created two new rows in an existing entity. In this case, only exporting data to XML should be done ?
>
> 2. Functionality which I have implemented won't work with old data. In that case, how migration process should be carried
> out ?
>
> For example :
>
>
> - In my implementation, I am tracking leave applications against leave balance (i.e. before creating a leave application
> ,his/her current balance would be checked)
>
> - When an already approved leave is rejected, corresponding 'no of leaves'(calculated using a service) gets credited
> back to his/her balance
>
> - But,as per old data, there wont be any (stored) value for 'no of leaves'.
>
> - If at all I use above service (for calculating no of leaves from existing dates),it will give rise to inconsistency
> of data because 'calculated no of leaves' would not be calculated against some 'leave balance'
>
> Please guide me in this context.
>
>
> Thanks & Regards,
>
> Swapnil Sawant
>
> ________________________________
> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended
> recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>
> ______________________________________________________________________

Swapnil Sawant

RE: Help regarding migration services

Hi Jacques,

My implementation is about leave management. Some part of it's functionality is as follows :

- Appropriate leave balance data would be there for two basic types of agreements (permanent and contractual)
- Agreements would be applied to employee/s and thereby he/she would get some leave balance
- Whenever an employee creates new leave application, leave balance would be checked.
- Depending on leave balance, leave application may or may not be created

In short, I have implemented 'leave balance check' functionality.

Now, lets consider old data. We may find that different employees had applied for different number of leaves in total(e.g. empl1 had applied for 40,empl2 had applied for 50 leaves till now ) . So when newly added functionality would be applied to 'such old data' conflicts will be seen in data (as you can not keep on creating new agreements specific to employee to cop-up with no of leaves created by him/her)

Please suggest how to tackle this situation.

Thanks & regards,

Swapnil Sawant

-----Original Message-----
From: Jacques Le Roux [mailto:[hidden email]]
Sent: Thursday, July 01, 2010 2:07 PM
To: [hidden email]
Subject: Re: Help regarding migration services

Quick answer: this may help (examples)
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration

Jacques

Swapnil Sawant wrote:

______________________________________________________________________

This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

______________________________________________________________________

BJ Freeman

Re: Help regarding migration services

the Agreement has items that define how, when, and the amount things happen.
so putting the rules in the agreements for past leaves in the only
migration needed.

The partybenifits is where you put data.
this would show past leaves with their from and thru dates, as well as
benefit type, and available time.
if the Partyrelatinoship is used between company and employee this makes
flow easier. since benefits only happen after the relationship is a
employment type.

the leave balance check should check the benifits types with no thru
dates and the avialible time for each benifit type.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>

Swapnil Sawant sent the following on 7/1/2010 3:19 AM:

> Hi Jacques,
>
> My implementation is about leave management. Some part of it's functionality is as follows :
>
> - Appropriate leave balance data would be there for two basic types of agreements (permanent and contractual)
> - Agreements would be applied to employee/s and thereby he/she would get some leave balance
> - Whenever an employee creates new leave application, leave balance would be checked.
> - Depending on leave balance, leave application may or may not be created
>
> In short, I have implemented 'leave balance check' functionality.
>
> Now, lets consider old data. We may find that different employees had applied for different number of leaves in total(e.g. empl1 had applied for 40,empl2 had applied for 50 leaves till now ) . So when newly added functionality would be applied to 'such old data' conflicts will be seen in data (as you can not keep on creating new agreements specific to employee to cop-up with no of leaves created by him/her)
>
> Please suggest how to tackle this situation.
>
>
>
> Thanks& regards,
>
> Swapnil Sawant
>
> -----Original Message-----
> From: Jacques Le Roux [mailto:[hidden email]]
> Sent: Thursday, July 01, 2010 2:07 PM
> To: [hidden email]
> Subject: Re: Help regarding migration services
>
> Quick answer: this may help (examples)
> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
>
> Jacques
>
> Swapnil Sawant wrote:
>> Hi,
>>
>> I have following queries while writing migration service/s :
>>
>>
>> 1. I have created two new rows in an existing entity. In this case, only exporting data to XML should be done ?
>>
>> 2. Functionality which I have implemented won't work with old data. In that case, how migration process should be carried
>> out ?
>>
>> For example :
>>
>>
>> - In my implementation, I am tracking leave applications against leave balance (i.e. before creating a leave application
>> ,his/her current balance would be checked)
>>
>> - When an already approved leave is rejected, corresponding 'no of leaves'(calculated using a service) gets credited
>> back to his/her balance
>>
>> - But,as per old data, there wont be any (stored) value for 'no of leaves'.
>>
>> - If at all I use above service (for calculating no of leaves from existing dates),it will give rise to inconsistency
>> of data because 'calculated no of leaves' would not be calculated against some 'leave balance'
>>
>> Please guide me in this context.
>>
>>
>> Thanks& Regards,
>>
>> Swapnil Sawant
>>
>> ________________________________
>> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended
>> recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>>
>> ______________________________________________________________________
>
>
> ______________________________________________________________________
>
> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>
> ______________________________________________________________________
>

Swapnil Sawant

RE: Help regarding migration services

Hi BJ,

I have following concerns in migration service you have mentioned below :

- In old data, we may see that different employees had taken different number of leaves for different number of times. Hence, its not feasible to decide upon some fixed count(leave balance) which would go into agreement data which migration service would prepare.

For example,

agreement data like total number of leaves is difficult to be put using migration service for old leave applications because while writing migration services we may not know as to how to adjust all older leave applications into fixed set of agreements(by default 2 i.re. for permanent and contractual) i.e what would be the exact value for 'total number of leaves' considering 'how many times an employee might have taken leaves in past'

Problem which I see over here is :

After new leave functionality comes into picture, our leave apps would be aligned as per leave balance. But, older leave apps would have different 'no. of leaves and available time per employee' .

Thanks & regards,

Swapnil Sawant

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Thursday, July 01, 2010 10:21 PM
To: [hidden email]
Subject: Re: Help regarding migration services

the Agreement has items that define how, when, and the amount things happen.
so putting the rules in the agreements for past leaves in the only
migration needed.

The partybenifits is where you put data.
this would show past leaves with their from and thru dates, as well as
benefit type, and available time.
if the Partyrelatinoship is used between company and employee this makes
flow easier. since benefits only happen after the relationship is a
employment type.

the leave balance check should check the benifits types with no thru
dates and the avialible time for each benifit type.

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>

Swapnil Sawant sent the following on 7/1/2010 3:19 AM:

BJ Freeman

Re: Help regarding migration services

here is how the Agreement model should be setup
Agreements is to specify when leaves should happen like every 6 months,
or so many hours leave for so many hours worked.

In migration, if you want a audit trail, you will need to reconstruct
the rules of how the leave was calculated for a given period.
if the rules are the same as current then there is no reconstruction
necessary.

the model for figuring leave

A service calculates and updates partybenifits.availabletime, for
partybenfits.from to partybenfits.thru, of the partybenfits.benefittype
of leave, based on the Agreement. I suggest a nightly run service to do
this.

As the partybenfits.benefittype of leave is used for partybenfits.from
to partybenfits.thru the partybenfits.availabletime field is decremented
till zero or the partybenfits.thru is reached.

if the partybenfits.thru date is past the current date, then what is
left in the available time is no longer usable. if the
partybenfits.Fromdate is a date in the future it can not be used in
calculating current partybenfits.benefittype of leave for the party.

Old leave is specified with the partybenfits.availabletime, if not all
used, with partybenfits.from to partybenfits.thru as to when it was
available.
using this model will not cause a conflict.

the migration service will only run once.

I have simplified the explantion for clarity.
in acutual use you will find the partyID.roletype employee
partiesrelationship.roletype employment related to agreement(s) and
partybenefits. these would be entityviews.

There is normally only one agreement,with many agreementItems. There are
many partybenefits records per partyID.roletype employee with a
partyrelatiohship.type of employement.

Hope that helps

Swapnil Sawant sent the following on 7/1/2010 8:59 PM:

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>

> Hi BJ,
>
> I have following concerns in migration service you have mentioned below :
>
> - In old data, we may see that different employees had taken different number of leaves for different number of times. Hence, its not feasible to decide upon some fixed count(leave balance) which would go into agreement data which migration service would prepare.
>
> For example,
>
> agreement data like total number of leaves is difficult to be put using migration service for old leave applications because while writing migration services we may not know as to how to adjust all older leave applications into fixed set of agreements(by default 2 i.re. for permanent and contractual) i.e what would be the exact value for 'total number of leaves' considering 'how many times an employee might have taken leaves in past'
>
> Problem which I see over here is :
>
> After new leave functionality comes into picture, our leave apps would be aligned as per leave balance. But, older leave apps would have different 'no. of leaves and available time per employee' .
>
>
> Thanks& regards,
>
> Swapnil Sawant
>
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Thursday, July 01, 2010 10:21 PM
> To: [hidden email]
> Subject: Re: Help regarding migration services
>
> the Agreement has items that define how, when, and the amount things happen.
> so putting the rules in the agreements for past leaves in the only
> migration needed.
>
> The partybenifits is where you put data.
> this would show past leaves with their from and thru dates, as well as
> benefit type, and available time.
> if the Partyrelatinoship is used between company and employee this makes
> flow easier. since benefits only happen after the relationship is a
> employment type.
>
> the leave balance check should check the benifits types with no thru
> dates and the avialible time for each benifit type.
>
>
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com<http://www.specialtymarket.com/>
>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
> Linkedin
> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>
>
> Swapnil Sawant sent the following on 7/1/2010 3:19 AM:
>> Hi Jacques,
>>
>> My implementation is about leave management. Some part of it's functionality is as follows :
>>
>> - Appropriate leave balance data would be there for two basic types of agreements (permanent and contractual)
>> - Agreements would be applied to employee/s and thereby he/she would get some leave balance
>> - Whenever an employee creates new leave application, leave balance would be checked.
>> - Depending on leave balance, leave application may or may not be created
>>
>> In short, I have implemented 'leave balance check' functionality.
>>
>> Now, lets consider old data. We may find that different employees had applied for different number of leaves in total(e.g. empl1 had applied for 40,empl2 had applied for 50 leaves till now ) . So when newly added functionality would be applied to 'such old data' conflicts will be seen in data (as you can not keep on creating new agreements specific to employee to cop-up with no of leaves created by him/her)
>>
>> Please suggest how to tackle this situation.
>>
>>
>>
>> Thanks& regards,
>>
>> Swapnil Sawant
>>
>> -----Original Message-----
>> From: Jacques Le Roux [mailto:[hidden email]]
>> Sent: Thursday, July 01, 2010 2:07 PM
>> To: [hidden email]
>> Subject: Re: Help regarding migration services
>>
>> Quick answer: this may help (examples)
>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
>>
>> Jacques
>>
>> Swapnil Sawant wrote:
>>> Hi,
>>>
>>> I have following queries while writing migration service/s :
>>>
>>>
>>> 1. I have created two new rows in an existing entity. In this case, only exporting data to XML should be done ?
>>>
>>> 2. Functionality which I have implemented won't work with old data. In that case, how migration process should be carried
>>> out ?
>>>
>>> For example :
>>>
>>>
>>> - In my implementation, I am tracking leave applications against leave balance (i.e. before creating a leave application
>>> ,his/her current balance would be checked)
>>>
>>> - When an already approved leave is rejected, corresponding 'no of leaves'(calculated using a service) gets credited
>>> back to his/her balance
>>>
>>> - But,as per old data, there wont be any (stored) value for 'no of leaves'.
>>>
>>> - If at all I use above service (for calculating no of leaves from existing dates),it will give rise to inconsistency
>>> of data because 'calculated no of leaves' would not be calculated against some 'leave balance'
>>>
>>> Please guide me in this context.
>>>
>>>
>>> Thanks& Regards,
>>>
>>> Swapnil Sawant
>>>
>>> ________________________________
>>> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended
>>> recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>>>
>>> ______________________________________________________________________
>>
>>
>> ______________________________________________________________________
>>
>> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>>
>> ______________________________________________________________________
>>
>
>
> ______________________________________________________________________
>
> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>
> ______________________________________________________________________
>

Swapnil Sawant

RE: Help regarding migration services

Hi BJ,

In ofbiz leave functionality, currently there is no such concept of 'defined rules for how the leave was calculated for a given period'. Hence, below solution doesn't seem to be feasible from implementation perspective.

Hence, we would upload patch for review purpose and would work on 'finding feasible solution for migration services' parallely.

Thanks & Regards,
Swapnil Sawant

-----Original Message-----
From: BJ Freeman [mailto:[hidden email]]
Sent: Friday, July 02, 2010 1:47 PM
To: [hidden email]
Subject: Re: Help regarding migration services

here is how the Agreement model should be setup
Agreements is to specify when leaves should happen like every 6 months,
or so many hours leave for so many hours worked.

In migration, if you want a audit trail, you will need to reconstruct
the rules of how the leave was calculated for a given period.
if the rules are the same as current then there is no reconstruction
necessary.

the model for figuring leave

A service calculates and updates partybenifits.availabletime, for
partybenfits.from to partybenfits.thru, of the partybenfits.benefittype
of leave, based on the Agreement. I suggest a nightly run service to do
this.

As the partybenfits.benefittype of leave is used for partybenfits.from
to partybenfits.thru the partybenfits.availabletime field is decremented
till zero or the partybenfits.thru is reached.

if the partybenfits.thru date is past the current date, then what is
left in the available time is no longer usable. if the
partybenfits.Fromdate is a date in the future it can not be used in
calculating current partybenfits.benefittype of leave for the party.

Old leave is specified with the partybenfits.availabletime, if not all
used, with partybenfits.from to partybenfits.thru as to when it was
available.
using this model will not cause a conflict.

the migration service will only run once.

I have simplified the explantion for clarity.
in acutual use you will find the partyID.roletype employee
partiesrelationship.roletype employment related to agreement(s) and
partybenefits. these would be entityviews.

There is normally only one agreement,with many agreementItems. There are
many partybenefits records per partyID.roletype employee with a
partyrelatiohship.type of employement.

Hope that helps

Swapnil Sawant sent the following on 7/1/2010 8:59 PM:

=========================
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>

BJ Freeman

Re: Help regarding migration services

I respect your efforts, only sad I will not be something I can use,
since my version follows the Data Model books, closer than ofbiz does.

Swapnil Sawant sent the following on 7/6/2010 4:11 AM:

=========================
BJ Freeman <http://bjfreeman.elance.com>
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man

> Hi BJ,
>
> In ofbiz leave functionality, currently there is no such concept of 'defined rules for how the leave was calculated for a given period'. Hence, below solution doesn't seem to be feasible from implementation perspective.
>
> Hence, we would upload patch for review purpose and would work on 'finding feasible solution for migration services' parallely.
>
>
>
> Thanks& Regards,
> Swapnil Sawant
>
>
> -----Original Message-----
> From: BJ Freeman [mailto:[hidden email]]
> Sent: Friday, July 02, 2010 1:47 PM
> To: [hidden email]
> Subject: Re: Help regarding migration services
>
> here is how the Agreement model should be setup
> Agreements is to specify when leaves should happen like every 6 months,
> or so many hours leave for so many hours worked.
>
> In migration, if you want a audit trail, you will need to reconstruct
> the rules of how the leave was calculated for a given period.
> if the rules are the same as current then there is no reconstruction
> necessary.
>
> the model for figuring leave
>
> A service calculates and updates partybenifits.availabletime, for
> partybenfits.from to partybenfits.thru, of the partybenfits.benefittype
> of leave, based on the Agreement. I suggest a nightly run service to do
> this.
>
> As the partybenfits.benefittype of leave is used for partybenfits.from
> to partybenfits.thru the partybenfits.availabletime field is decremented
> till zero or the partybenfits.thru is reached.
>
>
> if the partybenfits.thru date is past the current date, then what is
> left in the available time is no longer usable. if the
> partybenfits.Fromdate is a date in the future it can not be used in
> calculating current partybenfits.benefittype of leave for the party.
>
> Old leave is specified with the partybenfits.availabletime, if not all
> used, with partybenfits.from to partybenfits.thru as to when it was
> available.
> using this model will not cause a conflict.
>
> the migration service will only run once.
>
> I have simplified the explantion for clarity.
> in acutual use you will find the partyID.roletype employee
> partiesrelationship.roletype employment related to agreement(s) and
> partybenefits. these would be entityviews.
>
> There is normally only one agreement,with many agreementItems. There are
> many partybenefits records per partyID.roletype employee with a
> partyrelatiohship.type of employement.
>
> Hope that helps
>
>
> Swapnil Sawant sent the following on 7/1/2010 8:59 PM:
>
>
> =========================
> BJ Freeman
> http://bjfreeman.elance.com
> Strategic Power Office with Supplier Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com<http://www.specialtymarket.com/>
>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
> Linkedin
> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>
>> Hi BJ,
>>
>> I have following concerns in migration service you have mentioned below :
>>
>> - In old data, we may see that different employees had taken different number of leaves for different number of times. Hence, its not feasible to decide upon some fixed count(leave balance) which would go into agreement data which migration service would prepare.
>>
>> For example,
>>
>> agreement data like total number of leaves is difficult to be put using migration service for old leave applications because while writing migration services we may not know as to how to adjust all older leave applications into fixed set of agreements(by default 2 i.re. for permanent and contractual) i.e what would be the exact value for 'total number of leaves' considering 'how many times an employee might have taken leaves in past'
>>
>> Problem which I see over here is :
>>
>> After new leave functionality comes into picture, our leave apps would be aligned as per leave balance. But, older leave apps would have different 'no. of leaves and available time per employee' .
>>
>>
>> Thanks& regards,
>>
>> Swapnil Sawant
>>
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:[hidden email]]
>> Sent: Thursday, July 01, 2010 10:21 PM
>> To: [hidden email]
>> Subject: Re: Help regarding migration services
>>
>> the Agreement has items that define how, when, and the amount things happen.
>> so putting the rules in the agreements for past leaves in the only
>> migration needed.
>>
>> The partybenifits is where you put data.
>> this would show past leaves with their from and thru dates, as well as
>> benefit type, and available time.
>> if the Partyrelatinoship is used between company and employee this makes
>> flow easier. since benefits only happen after the relationship is a
>> employment type.
>>
>> the leave balance check should check the benifits types with no thru
>> dates and the avialible time for each benifit type.
>>
>>
>> =========================
>> BJ Freeman
>> http://bjfreeman.elance.com
>> Strategic Power Office with Supplier Automation<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>> Linkedin
>> <http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>
>>
>>
>> Swapnil Sawant sent the following on 7/1/2010 3:19 AM:
>>> Hi Jacques,
>>>
>>> My implementation is about leave management. Some part of it's functionality is as follows :
>>>
>>> - Appropriate leave balance data would be there for two basic types of agreements (permanent and contractual)
>>> - Agreements would be applied to employee/s and thereby he/she would get some leave balance
>>> - Whenever an employee creates new leave application, leave balance would be checked.
>>> - Depending on leave balance, leave application may or may not be created
>>>
>>> In short, I have implemented 'leave balance check' functionality.
>>>
>>> Now, lets consider old data. We may find that different employees had applied for different number of leaves in total(e.g. empl1 had applied for 40,empl2 had applied for 50 leaves till now ) . So when newly added functionality would be applied to 'such old data' conflicts will be seen in data (as you can not keep on creating new agreements specific to employee to cop-up with no of leaves created by him/her)
>>>
>>> Please suggest how to tackle this situation.
>>>
>>>
>>>
>>> Thanks& regards,
>>>
>>> Swapnil Sawant
>>>
>>> -----Original Message-----
>>> From: Jacques Le Roux [mailto:[hidden email]]
>>> Sent: Thursday, July 01, 2010 2:07 PM
>>> To: [hidden email]
>>> Subject: Re: Help regarding migration services
>>>
>>> Quick answer: this may help (examples)
>>> https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
>>>
>>> Jacques
>>>
>>> Swapnil Sawant wrote:
>>>> Hi,
>>>>
>>>> I have following queries while writing migration service/s :
>>>>
>>>>
>>>> 1. I have created two new rows in an existing entity. In this case, only exporting data to XML should be done ?
>>>>
>>>> 2. Functionality which I have implemented won't work with old data. In that case, how migration process should be carried
>>>> out ?
>>>>
>>>> For example :
>>>>
>>>>
>>>> - In my implementation, I am tracking leave applications against leave balance (i.e. before creating a leave application
>>>> ,his/her current balance would be checked)
>>>>
>>>> - When an already approved leave is rejected, corresponding 'no of leaves'(calculated using a service) gets credited
>>>> back to his/her balance
>>>>
>>>> - But,as per old data, there wont be any (stored) value for 'no of leaves'.
>>>>
>>>> - If at all I use above service (for calculating no of leaves from existing dates),it will give rise to inconsistency
>>>> of data because 'calculated no of leaves' would not be calculated against some 'leave balance'
>>>>
>>>> Please guide me in this context.
>>>>
>>>>
>>>> Thanks& Regards,
>>>>
>>>> Swapnil Sawant
>>>>
>>>> ________________________________
>>>> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended
>>>> recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>>>>
>>>> ______________________________________________________________________
>>>
>>>
>>> ______________________________________________________________________
>>>
>>> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>>>
>>> ______________________________________________________________________
>>>
>>
>>
>> ______________________________________________________________________
>>
>> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>>
>> ______________________________________________________________________
>>
>
> ______________________________________________________________________
>
> This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
>
> ______________________________________________________________________
>