Yes, that looks like a bug. Can you please file a jira with these details? Its possible to extend oozie EL functions and provide a custom EL function. Sorry, I couldn't find the documentation. You can file a jira for that as well.
In Apache falcon project, we have extended these EL functions and provided EL functions like: 1. currentMonth(day, hr, min) - current month resolves to the beginning of current month with respect to nominal time. day, hr and min are offsets with respect to the resolved time 2. lastMonth(day, hour, min) - last month resolves to the beginning of previous month with respect to nominal time. day, hr and min are offsets with respect to the resolved time For your usecase, you can use start as lastMonth(0, 0, 0) and end as currentMonth(0, -1, 0). These start and end functions need not be changed even if you change the nominal time to any other time in the same month. The code for this is at https://github.com/apache/incubator-falcon/tree/master/oozie-el-extensions. You can either use this or use it as a reference to write your own EL functions. You need to include the EL implementation jar in oozie server(libext) and oozie-site.xml should have the corresponding configs. -Shwetha On Mon, Dec 1, 2014 at 9:59 PM, J. McConnell <[email protected]> wrote: > On Sun, Nov 30, 2014 at 6:54 AM, Idris Ali <[email protected]> wrote: > > > > > If the intention is to read hourly data for a month, then the simplest > way > > is to specify like this. > > > > <data-in name="input" dataset="logs"> > > <start-instance>${coord:current( -(coord:daysInMonth(0) - > > 1)*24 )}</start-instance> > > <end-instance>${coord:current(0)}</end-instance> > > </data-in> > > > > This takes care of any month, however special handling is required for > > daylight saving timezone, for details refer the coordinator functional > spec > > here. > > > Yes, that is indeed the intention and this was my first thought. However, > it is the special handling for daylight saving time that I am specifically > looking to avoid. I don't see anything in the coordinator functional spec > that will help with this. The coord:hoursInDay() function is great, but > what is needed in this case is a coord:hoursInMonth() function. > > That said, I thought the approach of using the coord:offset() function > would be a good way of doing this, but I've hit what appears to be a bug. > Can anyone confirm that this is indeed a bug? Does anyone know of a good > workaround, either with coord:daysInMonth()/hoursInDay() or some other way? > Is it possible to extend the EL language locally to support an > hoursInMonth() method? > > Any help would be appreciated. Thanks, > > - J. > -- _____________________________________________________________ The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.
