Hello Peter
Active Record does not currently have special support for `postgres_fdw`.
There are also no plans to add that in the near future.
If someone is interested in picking up the idea, I think it's best to
explore it in a gem first.
Cheers,
-- Yves
On Tuesday, September 22, 2015 at
1. `add_column` is a lower level building block than `t.column`. The higher
level methods are composed of these lower level building blocks.
That's why you get more combined behavior when using higher level
constructs.
2. There is an open PR about PostgreSQL opclass support.
See
Hey Meghali
This mailing list is about the development of the web framework Ruby on
Rails.
You probably posted to the wrong mailing list.
Cheers,
-- Yves
On Tue, Aug 25, 2015 at 9:15 AM Meghali meghali.dho...@gmail.com wrote:
Hi All,
I have installed and tested Ruby (2.2.2) on ppc64le
Hey Bryan
I'm fine with supporting both `uniq` and `unique` in the generator. More so
because the option is called `unique`.
Cheers,
-- Yves
On Monday, June 15, 2015 at 4:25:29 PM UTC+2, Bryan Ash wrote:
The generator for unique indices seems inconsistent to me.
rails g migration
I personally don't think we should spend time on expanding the horizon of
`db/schema.rb` for specific database adapters.
Sure, there are already very specific things in there but they generally
lead to issues down the line. With `db/structure.sql` we have a working
solution, maintained by the
that doesn’t happen very often
at all, since I’ve found indexed columns tend to be important and keep
their names.
So I would vote for meaningful names too. Just my 2c.
On 16/01/2015, at 01:42 , Yves Senn yves...@gmail.com javascript:
wrote:
Hey Chris
Sorry for my late response.
tl
Hey Chris
Sorry for my late response.
tl;dr: I'd rather not go for consistency with index naming but for a
consistent hash approach.
We have descriptive names for indexes because they are shown to the user in
query plans.
This is not the case with foreign keys. When inspecting a database you
happened when I found this. I has used model
generator and updated the migration manually. I will go through the code
and open a PR for model generator commenting out fixtures. Is it okey?
Thanks.
On Thu, Nov 20, 2014 at 2:32 AM, Yves Senn yves.s...@gmail.com wrote:
Hey
The fixtures should
Hey
The fixtures should satisfy not-null constraints if you specify everything
through the generator.
If you manipulate the migration directly, your fixtures won't be updated
accordingly.
I got bitten by this in the past. Especially because the model generator
does not generate concrete
Did you check that `self` in the context of your state-machine callback is the
actual model instance and not some different object? If it’s a meeting instance
like the one in the controller, a sample application would go a long way to
help us debug the issue. Would be great to have a minimal
Specifying the `:type` on `references` has already been added.
See https://github.com/rails/rails/pull/16231 for more details.
On Wednesday, September 3, 2014 11:54:50 PM UTC+2, Rafael Mendonça França
wrote:
Although there is the undocumented native_database_types method that
returns a hash
You should use Date.current. As far as I can remember, we don't patch
Date.today.
Cheers,
-- Yves
—
Sent from Mailbox
On Thu, Jul 10, 2014 at 11:51 AM, Michalis P mpola...@gmail.com wrote:
Hello all,
I just wanted to ask if this is normal/intended or just a bug.
[5] pry(main)
I agree with Matt on this subject. Even if we could come up with useful
heuristics, we would not deprecate includes, eager_load and preload. There
are always situations you can't detect. Also I wouldn't want to use that
feature on some of my apps. It can be crucial what Query is executed and
Hey Josef,
A PR that promotes the use of bin/* would be great. It is the suggested way
to run `rails` and `rake`.
Feel free to mention me on the PR if you have questions or for review.
Cheers,
-- Yves
On Tuesday, April 8, 2014 10:01:00 AM UTC+2, Josef Šimánek wrote:
Hello.
It looks like
Hi Olivier
We are probably not going to introduce support for this module in the upcoming
releases.
However I am working on the PostgreSQLAdapters type mapping. The goal is that
users
are able to register their own types. This would mean that you can introduce
support
for these types yourself
+1 from me as well. This would be a great addition to the current API.
Cheers,
-- Yves Senn
On 10.04.2014, at 18:41, Rafael Mendonça França rafaelmfra...@gmail.com wrote:
+1, too.
I was planning to add this method because calling `to_sql` is not a good
solution. I think the name we choose
We should keep #to_sql and Arel as private API. The use-case to get the raw
response from the driver remains.
It would be nice to use ActiveRecord to build the SQL but get access to the raw
driver result and not the mapped objects.
Do the lower level methods like `select_all`, `select_values`,
I completely agree with Ryan that you should not completely rely on the
generated scaffold code. However it is a good starting point when you need
a basic CRUD controller. It saves some typing and you can easily get rid of
stuff you don't need. As of the requested functionality. I remember a PR
Hey,
I agree with Gabriel Sobrinho. This check goes against the point of having
a NullRelation at all. Maybe you can provide more context about your
use-case and why you need that check.
On Monday, January 6, 2014 7:35:56 AM UTC+1, Shadab Ahmed wrote:
Hey,
I am passing a relation to a
development that's great! I'm sure you
will find work to do or someone who is willing to work on Rails.
--
Yves Senn
On Friday, July 19, 2013 3:22:22 AM UTC+2, richard schneeman wrote:
Maybe you can get together a local bug fixing support group that meets
once every other week and pairs on existing
I agree with Rafael. I don't see an obvious benefit over `builder.object`.
I think block arguments should not be used for optional data and in most
cases you don't need the `object`.
Am Freitag, 26. Oktober 2012 01:33:14 UTC+2 schrieb glaszig:
hello everybody.
i think it'd be very
I recently did a batch-processing operation, which simulated a calculation
with roughly 80'000 ActiveRecord objects. Since it was just a simulation
none of the records were actually persisted to the database. The
performance of the operation was pretty bad and I investigated a bit. I
could
22 matches
Mail list logo
