should be possible even is I'm not sure speed is relevant here (reading the file will always be much faster than inserting data). Thing I like with json/xml compared to sql/csv is the ability to add easily configuration and potentially metadata in entities themself. That said we can surely support csv since it is more or less the same query building logic.
Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-10-06 7:18 GMT+02:00 Chamil Jeewantha <[email protected]>: > Hi Romain, > > Useful += 1 > > I think this json format works for most of the scenarios. However when it > comes to bulk insertion requirements (several 100s/1000s of records), > A much simple CSV like format will work better. So If the architecture is > so generalized that can be extended to support many formats, We may > implement the CSV format in the future. > > WDYT? > > Best Regards, > Chamil > > > On Sun, Oct 5, 2014 at 6:27 PM, Romain Manni-Bucau <[email protected]> > wrote: > >> Hi >> >> opened https://issues.apache.org/jira/browse/TOMEE-1380 >> >> would be great to have feedbacks on it before digging into it. >> >> do you think: >> 1) it is useful/not >> 2) format is good >> ? >> >> >> Global idea is to provide 2 classes to import data using a datasource >> or an entitymanager. Then it would be integrated out of the box like >> to day our sql script feature and in tests with a JUnit rule surely. >> >> Main gain is to get a json format making it easier to maintain and in >> case of entitymanager it can be mapped to java instead of sql/jdbc. >> >> wdyt? >> >> >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> > > > > -- > http://kavimalla.blgospot.com > http://kdchamil.blogspot.com
