Review Board 1.5.4

jdegoes_issue_430

Updated 1 year, 3 months ago

John De Goes Reviewers
dchenbecker, dpp, marius, charles, joni, atsuhiko, jorge, naftoli, kris, indrajit, alexb, dlouwers, mstarzyk, rmellgren, jhoffman, probinett, jmadsen, mhartmann, jstrachan, jgoday
None LiftWeb-archive 
XSchema has been added to Lift Json. XSchema is an Avro-style JSON-based schema for data structures, tailored to functional languages, with code generators for Scala and HaXe.

The goal of this project is to support stable, robust, long-term persistence of pure data, along with generation of appropriate type classes (data ordering, equality, etc.).
XSchema is self-hosting, so all XSchema data structures are described by XSchema and generated by XSchema (the format of XSchema files is merely the XSchema-serialized XSchema data structures). XSchema generates a full suite of automated unit tests to make sure the user has specified appropriate defaults and to ensure that the code generator is working correctly. XSchema is also used in production at SocialMedia.com, with performance much faster than Java serialization or Lift Json serialization.
Ross Mellgren
Posted 1 year, 6 months ago (August 3rd, 2010, 7:12 p.m.)
I skimmed through perhaps 1/4th of the commit and ran out of time, but here are some disorganized questions/comments:
 
lift-json/benchmark seems like test stuff that should live somewhere in src/test

  1. Will let Joni comment on that, as he created the benchmark stuff.
  2. Yes, I will move benchmarks under src/test after complete rollover to SBT build is done. BTW. a performance degradation was noticed between 2.0-M7 and 2.0, it is on my todo list to fix that. The fix affects both schemaless serialization and xschema-based serialization, after that xschema-based serialization is 2-3 times faster than Java serialization I believe.

this seems like a bad definition, as x != y does not imply x compare y != 0
  1. That's residual code that should have been deleted. Will delete it now. (Good catch!)
Based on the change to pom.xml to use xschema-maven-plugin, shouldn't Data.scala (and any other codegen'ed files) not be committed, but instead be built by maven/sbt into generated-sources?
 
  1. That's not very convenient because when tweaking the code, you often run into a state where you generate bad code, and since XSchema is self-hosting, that's a show stopper. You always need to be able to get back to earlier versions of the generated code, in case Bad Things happen.
  2. understood, sounds fine to me
Ship it!
Joni Freeman
Posted 1 year, 6 months ago (August 4th, 2010, 2:31 a.m.)
This is a fantastic addition!

Some comments:

In Extraction.scala lines 288 and 295, should those List instantiations be at object level? Now list allocation is done for each function evaluation.

Some documentation should be added (but can be done after this initial push), either a new README file or addition to the existing one.
  1. Fixed, now they are object fields.

Am working on documentation now, but would like to get this out there since so many people are waiting on it.
Ship it!
Derek Chen-Becker
Posted 1 year, 5 months ago (August 14th, 2010, 5:49 a.m.)
Looks good, but it doesn't appear that there's a ticket associated with this...