side too). In fact you don't necessarily
> need a long lived database lock - it is sometimes easier to have a locked /
> locked_by attribute on the model, and only use an actual database lock (or
> optimistic locking) when writing to it.
>
> Actually blocking for a long time on som
tabase access,
for the locked object only, is waiting.
I need to block the cron task from executing any further than where the
lock is taken until the user task releases the lock (and vice versa). How
do I do that?
Thanks,
Yoram
--
You received this message because you are subscribed to the
Thanks all...
I ended up solving this much along the lines that Tim recommended -
lots of 'has_many' statements in the School model and several custom
built accessors such as those that Tim described.
I appreciate the help.
Yoram
On Mar 4, 9:29 am, Matt Jones wrote:
> On Mar 3, 4
I'm staying away from STI because I want to be able to add additional
asset types over time, none of which share attributes with other
assets. So - with STI, I could end up with a table that has hundreds
of columns.
On Mar 3, 1:13 pm, Colin Law wrote:
> On 3 March 2011 21:10, Yora
ongs_to :school
end
and
class School << ActiveRecord::Base
has_many :assets
end
That gets me part way there but I fear is fundamentally flawed. Most
of the time it results in complaints from raisl that the table
'Assets' doesn't exist, which is true...
Any suggestions
I was able to resolve this - in order to pull the db, I had to
increasemax_allowed_packet on MySQL
The weirdness on the invisible attribute was because of the way the
SELECT works:
http://caboo.se/doc/classes/ActiveRecord/MissingAttributeError.html
Yoram
--
Posted via http://www.ruby
I recently tried to pull a database from our server and load it into my
local MySQL. I got the dreaded 'MySQL server has gone away'. Digging a
little deeper, I found that it choked on the first User record. We
recently added several attributes of type 'binary' to the User object. I
suspected an iss
Thansk Luke. I'm not familiar with observers but will research them.
Not yet knowing exactly what they are, I liked the fact that the
after_save handler guarantees that all the after_save processing will
be completed in the same thread as the save itself, thus avoiding the
potential for any race co
missions << self
So - that works just great, as long as I never reload the emitter's
emissions (emitter.reload). If I do, then my new emission is gone.
Is there any way to force the new emission to really save in the
database before the after_save handler completes?
Thanks,
Yoram
per recommended renaming the
'src' folder in the log4r gems dir to 'lib'.
This magically works. I can now load my environment, although I still
get that pesky message about the specification file missing.
Any suggestion sas to how to clean this up would be very much
appr
; modal box (since it's the server that determines that the user's
> > credentials are missing).
>
> > Any ideas how to do this?
>
> > Thanks,
> > Yoram
--~--~-~--~~~---~--~~
You received this message because you are subscribed
11 matches
Mail list logo