we'll have a clearer idea of what
the future is looking like for queries where you actually need to manipulate
the join behaviour yourself.
On 08/12/2011, at 8:40 AM, Jordan Ritter wrote:
What type of concrete objects would you expect the ORM layer to return, if
such a method call
, Jordan Ritter j...@darkridge.com wrote:
What type of concrete objects would you expect the ORM layer to return, if
such a method call existed? Outer joins tend to be used for getting mixed
tuples of data that don't correspond to concrete ORM types. I can't
immediately fathom what any ORM's
Keep in mind two things:
1. The default character encoding for DataObjects is UTF-8
2. With MySQL's VARCHAR(n), n is the # of *chars* under the current
character encoding the field can contain. This is not the same as the # of
*bytes* it can contain.
VARCHAR's maximum size
What version of data_objects, do_sqlite3 and dm-core?
cheers,
--jordan
On Feb 18, 2011, at 6:02 AM, Josh Moore wrote:
HI I am in the process of switching a rails 3 project from ActiveRecord to
Datamapper. I am using sqlite3 in development now and whenever I load a
model I get this error:
,
--jordan
On Feb 18, 2011, at 12:58 PM, Jordan Ritter wrote:
What version of data_objects, do_sqlite3 and dm-core?
cheers,
--jordan
On Feb 18, 2011, at 6:02 AM, Josh Moore wrote:
HI I am in the process of switching a rails 3 project from ActiveRecord to
Datamapper. I am using sqlite3
OOC, what kind of warnings are you getting?
I've heard a 1.1 release is imminent (in the next week or two).
cheers,
--jordan
On Feb 9, 2011, at 11:39 AM, Gary Yngve wrote:
We're getting annoyed with all the deprecation warnings in
dm-validations-1.0.2.
What's the roadmap for the next DM
Jake,
I just tried it myself with the current version of DM and see the
expected results.
Can you post an example script/snippet demonstrating your problem, and include
what version of which DM gems you're using?
cheers,
--jordan
On Jan 12, 2011, at 9:09 AM, jkestr wrote:
I have
On Sep 22, 2010, at 4:18 AM, Piotr Solnica wrote:
On Sep 22, 12:53 pm, postmodern postmodern.m...@gmail.com wrote:
Also, I thought we could eventually kick the Enum/Flags types out of
dm-types and into
dm-types-legacy.
That's a tough one. Dan always advocates people to use String
with
continue further down this path. We're going to work on it
this weekend.
cheers,
--jordan
On Sep 2, 2010, at 10:03 PM, Gernot wrote:
Hi Jordan
On 2 Sep., 04:05, Jordan Ritter j...@darkridge.com wrote:
Gernot,
While there may be syntactically better ways to construct your
continue further down this path. We're going to work on it
this weekend.
cheers,
--jordan
On Sep 2, 2010, at 10:03 PM, Gernot wrote:
Hi Jordan
On 2 Sep., 04:05, Jordan Ritter j...@darkridge.com wrote:
Gernot,
While there may be syntactically better ways to construct your
Gernot,
While there may be syntactically better ways to construct your
particular DM queries, I don't necessarily think you're going about it all
wrong. The truth is that the current logic behind generating JOINs for many
sophisticated (multi-table) join scenarios is plain broken.
IME, the meanings of safe vs. bang methods and what class of errors do
exceptions represent have always been, at their core, a conscious
philosophical difference between DM and AR.
One (much older) school of thought: exceptions are exceptional behaviour --
they typically represent
FWIW, I agree with your perspective on extlib's dwindling value. I think the
reaction to active_support (which I initially share) is really just due to the
historical observation that Rails and its components traditionally assumed they
were the only game in town, and didn't play easily/nicely
The code to support it would be pretty easy inside DM itself - just need a
monkeypatch/extension of DataMapper::Adapters::DataObjectsAdapter#create +
#insert_statement.
But the question to which I don't have an off-the-cuff answer is: what would a
well-formed/elegant usage of it look like?
I believe the issue you've just described is outlined in a pending DataMapper
ticket:
http://datamapper.lighthouseapp.com/projects/20609/tickets/1105-add-support-for-definingchanging-default-collation#ticket-1105-1
cheers,
--jordan
On Nov 11, 2009, at 9:34 AM, Jeff Pollard wrote:
Roy,
Ditto here: in the past I've forgotten to set Phusion Passenger's
framework spawn method to conservative, which -- based on when my
app initializes its DB connection -- yielded shared file descriptors
across processes, resulting in that sort of error you just saw.
cheers,
--jordan
On Nov
In 0.10.x, I've never had much luck with the set_log invocation.I
always set it directly: ::DataMapper.logger = Logger.new.
Personally, I don't think anything is wrong with that as a convention.
cheers,
--jordan
On Oct 20, 2009, at 7:42 PM, sliu wrote:
Thanks, martin.
Last night I
The logging initialization and internals may differ, but (insofar as
it-works-for-me) they both call the same methods to actually log data.
I currently hook all Rails and DM related logging with one object that
derives from Logger. If you simply assign a Logger.new (or anything
that
I do the same thing: ::DataMapper.logger = Logger.new(...) (DM
0.10x) before calling ::DataMapper::setup, in order to catch all
logging that it might emit.
I think the push/ Logger methods you're looking for are in Extlib
(which DM uses), which I believe was originally copied from Merb.
19 matches
Mail list logo
