On Dec 12, 2007 10:14 AM, John Siracusa <[EMAIL PROTECTED]> wrote:
> The basic idea (safe repeated auto-generation with all customizations
> stored elsewhere) has been done several different ways in RDBO by
> others, and I've been meaning to formalize at least one way to do it.
> But I don't think
On Sep 3, 2007 9:57 PM, Kurt Hansen <[EMAIL PROTECTED]> wrote:
> John Siracusa wrote:
> > On 9/3/07 12:31 PM, Kurt Hansen wrote:
> >
> >> However, I did not try the "connect_options" method based on your
> >> "inlined into the DSN" comment and reading up on the Rose::DB and DBI
> >> docs. The SSL o
On Aug 7, 2007 4:12 PM, George Hartzell <[EMAIL PROTECTED]> wrote:
> The following little fragment of sql does what I'd like it to do,
> inserts the current timestamp into the created_date column.
>
> create table mooses (
> id integer primary key autoincrement,
> name text,
>
On Aug 15, 2007 3:49 PM, Tim Bunce <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 15, 2007 at 01:06:01PM -0500, Graham Barr wrote:
> >
> > Rose::DB does not know that the $dbh it get back from connect is not a
> > newly connected handle. As a result is still goes ahead and calls init_dbh
> > which will s
> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> Okay, now I have a new favorite: undef_overrides_default
significant_undef :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security
On Dec 12, 2007 10:31 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> FWIW I'd use POD markup to separate custom code from auto-generated
> code. It's safe, has markup properties, and can contain a comment about
> its purpose.
I'm more inclined to use separate .pm files, if only to keep version
con
On Dec 12, 2007 9:48 AM, Peter Karman <[EMAIL PROTECTED]> wrote:
> I don't see this in Changes in current RDBO svn. Any chance it could be
> included in the next release?
It's in SVN now. Thanks for the reminder.
-John
-
S
Quoting John Siracusa <[EMAIL PROTECTED]>:
>> explicit_null
>
> That's closer, but it feels like even less of a complete description
> than undef_sets_null.
>
Perhaps it should involve 'default' somehow? undef_ignores_default or
something?
adam
-
On Wed, 12 Dec 2007 10:14:27 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote:
JS> The basic idea (safe repeated auto-generation with all
JS> customizations stored elsewhere) has been done several different
JS> ways in RDBO by others, and I've been meaning to formalize at least
JS> one way to do i
On Dec 12, 2007 8:45 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> I played with the Cayenne Java ORM last week. I didn't like it much
> (it's very inferior to RDBO, especially in auto-generating from the
> schema), but one idea that caught my eye was the 'auto' hierarchy.
> Basically you get a hi
On Dec 12, 2007 8:43 AM, John Siracusa <[EMAIL PROTECTED]> wrote:
> Undef is always treated as null. The distinction in this case is that
> explicitly setting the column to undef overrides the default value.
Okay, now I have a new favorite: undef_overrides_default
That's pretty long, but it's th
On 10/24/2007 10:59 AM, Peter Karman wrote:
>
> On 10/24/2007 10:50 AM, John Siracusa wrote:
>> Anyway, I can't decide if this is a bug or not. You tell me :) What's more
>> appropriate for the loader to produce for an "integer auto-increment" db
>> column definition? An "integer" column tha
On Dec 12, 2007 8:34 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Dec 2007 12:10:00 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote:
> JS> The undef_sets_null feature that alters the behavior of default
> JS> columns values will almost certainly go out in the next release (which
> JS> i
I played with the Cayenne Java ORM last week. I didn't like it much
(it's very inferior to RDBO, especially in auto-generating from the
schema), but one idea that caught my eye was the 'auto' hierarchy.
Basically you get a hierarchy like this (naming simplified):
cayenne.BaseObject
parent of
On Tue, 11 Dec 2007 12:10:00 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote:
JS> The undef_sets_null feature that alters the behavior of default
JS> columns values will almost certainly go out in the next release (which
JS> is coming soon). It may or may not be public (depending on if I have
JS
15 matches
Mail list logo