Hello,
what C::V would you recommend for graph drawing? It should not be
abandoned by author a year ago at version 0.02 and be more or less
working and stable.
Alex
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/ma
* Tobias Kremer [2011-10-07 15:00]:
> I've written about this issue a couple of times in the past and it
> seems that this still hasn't been fixed.
Maybe the answer is mu.
Why use a session at all?
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http:/
Hi Janne,
I appreciate your taking the time to look into this. Unfortunately your patches
are for the Store::DBI backend, whereas I'm using Store::DBIC (DBIx::Class).
The INSERT IGNORE solution is probably exactly what this case needs, but as you
said, it's MySQL-specific and thus not suitable
On Fri, 7 Oct 2011, Janne Snabb wrote:
> Something like this perhaps? Untested code.
Sorry about flooding. This is another much simpler solution but works
only on MySQL. I think there is no standard SQL syntax to accomplish
the same without extra DB fields.
--
Janne Snabb / EPIPE Communications
On Fri, 7 Oct 2011, Janne Snabb wrote:
> I think the proper way to solve it is to drop the constraint on the
> cookie and just insert the cookie and have an auto_increment ID in
> the table. And when reading, select the cookie with the highest ID
> (because there might be several).
Something like
JSON will try to encode in UTF-8 format and if the data is already in UTF-8,
most likely it will be double encoded.
This could be fixed in two ways:
1) when loading your UTF-8 data, convert it to perl's internal encoding with:
use Encoding qw(decode_utf8);
my $perl_encoded=decode_utf8($utf_enc
On Fri, 7 Oct 2011, Erik Wasser wrote:
> How will the session key calculated? Any idea? Randomly? So two random
> processes will calculate the same session value?
It is still the same session cookie as before, but it has already
expired from the database? Thus both sessions try to re-insert it
s
On Friday 07 October 2011 14:48:14 Tobias Kremer wrote:
> 3. Both requests try to insert a new session, one succeeds, the other
> dies(!) with a duplicate key constraint error from MySQL.
Sounds like this should be changed from "insert" to "insert_or_update"
which is wrapped within a transaction
On Friday 07 October 2011 14:48:14 Tobias Kremer wrote:
> I've written about this issue a couple of times in the past and it
> seems that this still hasn't been fixed. Here's what's happening:
>
> 1. Request A comes in with an expired session cookie, C::P::Session
> tries to find the session for
As I sayed in one another thread, I have developped a simple Catalyst
application to test this utf-8 bug. You can download it at
http://gilles.tk/TestUTF8-0.01.tar.gz
Only simple catalyst.pl calls, a simple sqlite3 database, using
default debian environnement.
I have added a line in the sqlite dat
2011/10/7 Oliver Gorwits :
>> AutoCRUD is definitely maintained, and generally works very well.
>>
>> 'No sources defined' sounds to me like possibly your AutoCRUD config is
>> wrong... I can't read the demo from here though, so can't help with
>> specific advice, sorry.
>
> I released a new beta o
On Oct 7, 2011, at 12:22 AM, Stephen Clouse wrote:
> On Fri, Oct 7, 2011 at 12:05 AM, Toby Corkindale wrote:
> Is there a Plugin::CHI or a CHI driver for Plugin::Cache anywhere?
>
> CHI works fine with C::P::Cache out of the box, nothing extra required.
>
> Just specify class => 'CHI' in the b
Dear all,
I've written about this issue a couple of times in the past and it
seems that this still hasn't been fixed. Here's what's happening:
1. Request A comes in with an expired session cookie, C::P::Session
tries to find the session for the given cookie but finds nothing.
2. Meanwhile, Reques
> I have hacked around this AutoCRUD JSON view, and end up with a solution
>
> It is probably a bad solution, as I can't imagine that
> Catalyst::JSON::View is wrong, but I wonder what is the correct way to
> do it.
In terms of AutoCRUD, I can't offer a lot more, only to add I'm very
pleased that
> AutoCRUD is definitely maintained, and generally works very well.
>
> 'No sources defined' sounds to me like possibly your AutoCRUD config is
> wrong... I can't read the demo from here though, so can't help with
> specific advice, sorry.
I released a new beta of AutoCRUD a couple of days ago, bu
AutoCRUD is definitely maintained, and generally works very well.
'No sources defined' sounds to me like possibly your AutoCRUD config is
wrong... I can't read the demo from here though, so can't help with specific
advice, sorry.
--
Sent from my phone. Please excuse terseness, typos and top-po
Hi,
I have installed and ran successfully the AutoCRUD plugin, I set up a
mysql database tables to use UT8 charset, the charset in the ajax
requests is utf-8, everything seems correct, except the data in the
grids are double encoded, that means é instead of é.
I am pretty sure that the data in t
Catalyst::Controller::DBIC::API was written for exactly that use case.
Cheers, Alex
Am 2011-09-12 16:38, schrieb Roland Philibert:
Thanks all for your suggestions so far.
I was I guess on the right track with JSON:XS but I had also seen REST
but so far I am still unsure as what the best way to
Hi Toby,
note that you can still use Cache::FastMmap with Catalyst::Plugin::Cache
(Config::General config file section):
class Cache::FastMmap
expires 3600
cache_size 8m
It took me also some time to find out which module is the 'old' and
which the 'new' one, docs need
On Fri, Oct 7, 2011 at 12:05 AM, Toby Corkindale wrote:
> Is there a Plugin::CHI or a CHI driver for Plugin::Cache anywhere?
>
CHI works fine with C::P::Cache out of the box, nothing extra required.
Just specify class => 'CHI' in the backend config and pass CHI configuration
as documented.
--
20 matches
Mail list logo
