yup ========================= BJ Freeman http://bjfreeman.elance.com Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93> 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> David E Jones sent the following on 3/15/2010 8:06 PM: > I'm sorry, was there a point in there somewhere? > > -David > > > On Mar 15, 2010, at 9:00 PM, BJ Freeman wrote: > >> that reminds me of the wolf and the three pigs. >> if you build something that has unrealistic requirements, then it will >> not function in the real world. >> the person making the requirements should be aware of what they are and >> the limits or usage. >> but to build something just to say you built is not what I call good design. >> >> Just to note, while I was documenting my way of doing things It was >> suggested I look at the datafile way. >> >> I have and have attempted to use it in good faith. >> I have realworld files that I handled long before coming to ofbiz that >> are gigs in size, so the requirements have been around since the early 90's >> >> >> ====================== >> >> BJ Freeman >> http://bjfreeman.elance.com >> Strategic Power Office with Supplier Automation >> <http://www.businessesnetwork.com/automation/viewforum.php?f=93> >> 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> >> >> >> David E Jones sent the following on 3/15/2010 6:48 PM: >>> Sorry, that's silly. A bug can't exist without a requirement. Where was >>> this requirement ever established? What in the design implies that this was >>> a requirement? The API very clearly represents a process that reads the >>> entire file into memory. >>> >>> It sounds like it doesn't meet a requirement that you came up with. That >>> isn't the definition of a "bug", well except for the purposes of trolling >>> on mailing lists I suppose. >>> >>> -David >>> >>> >>> On Mar 15, 2010, at 7:16 PM, BJ Freeman wrote: >>> >>>> when code will not handle real world data, it is broken. >>>> you and I discussed this when importing xml file and I choose to parse >>>> them manually instead of using DOM. >>>> So what term is there besides bug for broken design. >>>> >>>> ========================= >>>> BJ Freeman >>>> http://bjfreeman.elance.com >>>> Strategic Power Office with Supplier Automation >>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=93> >>>> 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> >>>> >>>> >>>> David E Jones sent the following on 3/15/2010 6:05 PM: >>>>> On Mar 15, 2010, at 6:58 PM, Adam Heath wrote: >>>>> >>>>>> BJ Freeman wrote: >>>>>>> one of my smaller import files (8mb) is taking forever to be read in and >>>>>>> there is no output. >>>>>>> I am seeing the memory rail against the max setting. >>>>>>> got this error. >>>>>> The datafile set of classes is very broken for large files. It has a >>>>>> List<Record>, which means it will copy the entire file into memory >>>>>> before doing anything with it. The datafile code is not designed to >>>>>> handle large files. >>>>>> >>>>>> I consider this a bug that needs to be fixed. Checking... >>>>> This should be possible, but may require API changes. The problem is >>>>> that, like XML, data files can be hierarchical and a "node" can have >>>>> header and footer lines in the file. >>>>> >>>>> I wouldn't consider this a bug, just like XML DOM parsing is not a "bug". >>>>> Of course, you're certainly entitled to your opinion. >>>>> >>>>> -David >>>>> >>>>> >>> >> > >
