Bug #101811 for JSON-String: Reason/use cases in description

Thu Jan 29 03:08:03 2015 PERLANCAR [...] cpan.org - Ticket created

Subject:

Reason/use cases in description

Hi, It would be nice if the documentation describes some use cases or reason for this module. Because normally one would just maintain the real data structure, and then when the JSON is needed it can just be encoded on the fly (and then cached, should performance is an issue).

Fri Jan 30 16:54:52 2015 BRUMMETT [...] cpan.org - Taken

Fri Jan 30 17:09:07 2015 BRUMMETT [...] cpan.org - Correspondence added

On Thu Jan 29 03:08:03 2015, PERLANCAR wrote: Show quoted text

> It would be nice if the documentation describes some use cases or > reason for this module. Because normally one would just maintain the > real data structure, and then when the JSON is needed it can just be > encoded on the fly (and then cached, should performance is an issue).

I will admit, my use case is probably unusual. I'm using an ORM (UR, also on CPAN) to load objects from a DB which have an attribute that holds JSON. I'm deserializing it and passing the data structure to another bit of code that might or might not change some of the data. After the entire request is complete, the ORM saves only the changed objects' data back to the DB. This way, the data structure is re-serialized only if it's changed, and the object's data is only written back to the DB if the it changes. Would an equivalent DBIx::Class example be good enough?

Fri Jan 30 17:09:07 2015 The RT System itself - Status changed from 'new' to 'open'

Fri Jan 30 22:03:00 2015 perlancar [...] gmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #101811] Reason/use cases in description
Date:	Sat, 31 Jan 2015 10:02:47 +0700
To:	bug-JSON-String [...] rt.cpan.org
From:	Perl Ancar <perlancar [...] gmail.com>

Thanks for replying. Sure, even just the use example with UR is useful to help users get an idea of how/where to use the module. On Sat, Jan 31, 2015 at 5:09 AM, Anthony Brummett via RT < bug-JSON-String@rt.cpan.org> wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=101811 > > > On Thu Jan 29 03:08:03 2015, PERLANCAR wrote:

> > It would be nice if the documentation describes some use cases or > > reason for this module. Because normally one would just maintain the > > real data structure, and then when the JSON is needed it can just be > > encoded on the fly (and then cached, should performance is an issue).

> > I will admit, my use case is probably unusual. I'm using an ORM (UR, also > on CPAN) to load objects from a DB which have an attribute that holds > JSON. I'm deserializing it and passing the data structure to another bit > of code that might or might not change some of the data. After the entire > request is complete, the ORM saves only the changed objects' data back to > the DB. > > This way, the data structure is re-serialized only if it's changed, and > the object's data is only written back to the DB if the it changes. > > Would an equivalent DBIx::Class example be good enough? > >

Fri Feb 13 17:08:43 2015 BRUMMETT [...] cpan.org - Correspondence added

On Fri Jan 30 22:03:00 2015, perlancar@gmail.com wrote: Show quoted text

> Thanks for replying. Sure, even just the use example with UR is useful to > help users get an idea of how/where to use the module.

I've added some generic looking code to the SYNOPSIS and DESCRIPTION sections of the POD in version 0.2.0 that describes the ORM use case. I'm going to resolve this issue, but go ahead and re-open it if you think it's still not clear.

Fri Feb 13 17:09:02 2015 BRUMMETT [...] cpan.org - Correspondence added

fixed in 0.2.0

Fri Feb 13 17:09:02 2015 BRUMMETT [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Feb 13 17:09:07 2015 BRUMMETT [...] cpan.org - Fixed in 0.2.0 added