> I'm willing to do the cleanup work. [..] Sounds great! The refactoring should certainly be 3.2-only.
Adding ‘getDataMap’ to 3.1 is up to you. I don’t have a strong preference either way. Andrus On Jan 9, 2014, at 4:32 PM, Mike Kienenberger <[email protected]> wrote: > I'm willing to do the cleanup work. I guess I can poll the user list > to see if anyone is actually using datamap mode (seems unlikely) in > their own projects. > > I can do it just for 3.2 if you want, or I can add the getDataMap method. > > As a workaround in my current 3.1 project, i went back to using the > cgen v1 hack of using entity as the mode, reading the datamap from the > entity (actually easier with entityUtils), then knowing that the file > creation timestamp of the newly-generated file will prevent the > generation process from running multiple times. > > On Thu, Jan 9, 2014 at 2:07 AM, Andrus Adamchik <[email protected]> > wrote: >> Yeah. Looks kinda stupid. There’s an asymmetry between EntityArtifact, that >> exports ObjEntity as “object” into Velocity context) and DataMapArtifact >> that exports self as “object”. >> >> I am +1 to clean it up. Perhaps as a stopgap for 3.1, we simply add >> “getDataMap()” method to DataMapArtifact? >> >> Andrus >> >> >> On Jan 7, 2014, at 4:28 PM, Mike Kienenberger <[email protected]> wrote: >> >>> Is it just me, or has the cgen templating been rewritten so that in >>> datamap mode, you can't actually access the datamap? Instead, you can >>> only access some datamap query information. >>> >>> That defeats the entire point of that mode. I called it "datamap" >>> mode for a reason, not "datamap-queries" :-) >>> >>> I was using this mode to generate DAO pattern objects, which requires >>> being able to iterate over all of the entities in a datamap. >>> >> >
