Re: [RDBO] Last chance to suggest a better name for undef_sets_null
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 time to do docs and add support for it to the rest of the column JS types), but the code will be there. I still think the name is kind of JS lame, however, and I'm open to suggestions. (some are inverted) undef_is_null undef_as_null undef_eq_null explicit_null Ted - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Last chance to suggest a better name for undef_sets_null
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 is coming soon). It may or may not be public (depending on if I have JS time to do docs and add support for it to the rest of the column JS types), but the code will be there. I still think the name is kind of JS lame, however, and I'm open to suggestions. (some are inverted) undef_is_null undef_as_null undef_eq_null Undef is always treated as null. The distinction in this case is that explicitly setting the column to undef overrides the default value. explicit_null That's closer, but it feels like even less of a complete description than undef_sets_null. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] sqlite serial column type
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 that behaves auto-increment-y (the current behavior) or a serial column that also behaves that way? I would prefer 'serial' so that the distinction can be mapped more granularly to a RHTMLO Field type. For example, the working column-to-field map I have now maps the 'serial' type to 'hidden' fields, while 'integer' maps to 'integer' fields. [Whether serial values should be hidden in a form is, of course, a matter of opinion, which is why the map will be configurable.] John- I don't see this in Changes in current RDBO svn. Any chance it could be included in the next release? thanks. pek -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Last chance to suggest a better name for undef_sets_null
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 the most descriptive so far. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ideas from Cayenne
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 it. But I don't think I'd choose the extra level of JS inheritance technique. I'm OK with any technique, as long as it regenerates classes safely when the schema changes. The extra inheritance is, now that I think about it, only tangential to what I really liked: the safe regeneration. 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. Ted - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ideas from Cayenne
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 hierarchy like this (naming simplified): cayenne.BaseObject parent of db.auto.A parent of db.A where auto.A inherits from BaseObject, and A inherits from auto.A. Customizations go in A. All the glue code (what Rose::DB::Object::Loader woult generate) goes in db.auto.A. Only the db.auto.* classes are regenerated after the first run (unless you explicitly ask to overwrite the db.* classes). You can set the base object to something other that BaseObject. I'm not sure that kind of thing is necessary in Perl where you can alter any class at any time. In fact, it'd probably complicate matters since, in RDBO, the metadata object is class data that has to be cloned into derived classes. So you'd have this vestigial meta object lurking in the middle auto class for no reason (and changes to it wouldn't affect derived classes). 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 I'd choose the extra level of inheritance technique. Rose::DB::Object::Loader already supports base objects, but not this kind of hierarchy AFAIK. It'd work (try it manually and see) but I don't think it's the best choice. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Last chance to suggest a better name for undef_sets_null
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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] sqlite serial column type
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 - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ideas from Cayenne
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 control diffs more transparent. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Last chance to suggest a better name for undef_sets_null
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] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Still fighting with transactions
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 set all the dbh attributes to the defaults.
The standard approach I recommend is to check for the existence of a
private attribute:
$dbh = DBI-connect_cached(...);
unless ($dbh-{private_foo_bar}) {
# is new connection
...
$dbh-{private_foo_bar} = ...some truee value...
}
This is the approach I've taken in Rose::DB 0.737, soon to be released...
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] help specifying a default datetime with SQLite and RDBO::Loader
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,
created_date datetime not null default current_timestamp
);
insert into mooses(name) values ('B. Moose');
insert into mooses(name) values ('Big Tex');
select * from mooses;
If I use Rose::DB::Object::Loader on the database created with the
above, it complains with:
insert() - Invalid default datetime: 'current_timestamp' at ... Object.pm
This is fixed in SVN. Such columns will not get a default value of now
-John
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] Remote DB connection over SSL to MySQL DB using Rose::DB
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 options DO need to be inlined into the DSN Okay, I'll make the change in SVN when I get a chance. These are in SVN now. -John - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] ideas from Cayenne
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 I'd choose the extra level of inheritance technique. Is there a brief summary or can list members provide a summary of which approaches they use? Thanks, Clayton -- Clayton Scott [EMAIL PROTECTED] - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
