Noel Burton-Krahn wrote:
On Sun, Oct 26, 2008 at 1:19 AM, Peter Rabbitson [EMAIL PROTECTED] wrote:
1) You call delete_all
2) You traverse the entire relationship chain, and start calling delete
on the resulting three backwards, depth first.
3) By the time you get to the main row that you
On Sat, 25 Oct 2008, Noel Burton-Krahn wrote:
Well, delete_all can't work the way its currently implemented if your
database enforces referential integrity, and if you do cascading
deletes with triggers, you don't need delete_all at all. If that's
If your DB enforces referencial integrity,
On Sun, 26 Oct 2008, Noel Burton-Krahn wrote:
Can you rephrase this second issue you are talking about, without
referring the the first one (which is ENOPROBLEM).
If you construct a sufficiently complex select_related clause, DBIx
will construct ambiguous SQL. Take a look at the SQL that
I'm trying to do the following
i have a table with 3 columns col1, col2 time
I want to create some methods that I can pass dbix resultsets into
that will generate new tables
the first byMin takes the time field and blanks out the seconds, generating a
new column called 'minutes'
I've a question about the best way to interpose in checking the
arguments passed from DBIC via DBI to DBD::Oracle::execute().
From DBD::Oracle docs
http://search.cpan.org/~pythian/DBD-Oracle-1.22/Oracle.pm#DBD::Oracle_and_Unicode
there's a strange situation.
Data fetched is always returned as
Hi guys,
I found a bug, spent some time on creating a patch (incl. a testcase),
but received no reply so far. Now I'm at a loss what to do next.. I'd
like to contribute to DBIC, but nobody has pointed out what I did wrong.
(In fact I received no answers to my posts - and I have no clue why it
BUCHMULLER Norbert wrote:
I just suspect that
my thread was ignored by accident.
Indeed it was. The functionality patch looks good in itself. However I
am not sure that the tests changes are appropriate. The test name is
88result_set_column which implies calling methods on a resultset. Yet
On Mon, 27 Oct 2008 22:41:26 +0100 Peter Rabbitson
[EMAIL PROTECTED] wrote:
Indeed it was. The functionality patch looks good in itself. However I
am not sure that the tests changes are appropriate. The test name is
88result_set_column which implies calling methods on a resultset. Yet
you
On Tue, 28 Oct 2008 00:10:12 +0100 BUCHMULLER Norbert
[EMAIL PROTECTED] wrote:
So, the patch for t/88_result_set_column.t contains modifications
related to 3 different issues:
1. a new test for chained search() and '+select'/'+as'
2. a new test for a $rs-get_column() for a nonexistent
On Fri, Oct 24, 2008 at 04:48:02PM -0700, Noel Burton-Krahn wrote:
Hi Peter,
The problem goes a little deeper: I applied this change to SVN, and
immediately saw the 60core.t unit test fail doing deep recursion.
Apparently this will break when there's a loop in the relationship
graph. So,
On Fri, Oct 24, 2008 at 02:26:35PM -0700, Noel Burton-Krahn wrote:
DBIx's cascading delete_all (in DBIx::Class::ResultSet) it broken,
because it deletes the parent table before it deletes the children.
The database will throw a referential integrity exception when the
parent is deleted before
On Fri, Oct 24, 2008 at 05:34:06PM +0400, jackal wrote:
On Friday 24 October 2008 17:11:46 Fayland Lam wrote:
hi, folks.
basically I prefers tinyint better than enum becaue I don't need alter
table when adding another value to col.
see now we have a column 'status' and it's tinyint
12 matches
Mail list logo
