Re: Object freeze and data reading

[David Espada]

2017-01-16 21:40 GMT+01:00 Jeremy Evans 


> Thanks.  This does appear to be a bug, caused because the associations
> hash was frozen before validation (freeze validates), when it probably
> shouldn't be frozen until after.
> .../...
> You could work around this issue by overriding Company#freeze to call
> positions before calling super.
>

Thank you. I have a work around applied already. It is enough that it is
solved by now ;)

Greets.

-- 
David

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations with sharded databases question

[Jeremy Evans]

On Monday, January 16, 2017 at 7:37:49 AM UTC-8, Jay Danielian wrote:
>
> I've been able to successfuly setup my sharded databases and load records 
> into it with my custom sharding scheme. So far I run 
> Sequel::Migrator.apply(DB, './migrate') and it picks up my migration 
> scripts. In my migration script I am doing this:
>
> Sequel.migration do 
>   up do 
> DB.each_server do |db|
>   db.create_table(:blah) ... 
>end 
> end
>
>
> And it works great - however I notice that the schema_info table is only 
> in my :default database (the first shard if you will). Is this expected? My 
> table is created with the proper schema in the "second" database shard, and 
> read/writes work fine - so everything is working. Just curious if its 
> expected to only write out the schema_info table on one of the databases.
>

The way you are using the migrator is not the correct way, that's why you 
end up with the schema_info table in only one database.  The correct way to 
do this would be to just have create_table in the migration, and call the 
migrator separately for each shard.  You'll need to use the migrator API 
for this, bin/sequel doesn't support it.

Thanks,
Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: Object freeze and data reading

[Jeremy Evans]

On Monday, January 16, 2017 at 2:10:31 AM UTC-8, David Espada wrote:
>
> 2017-01-13 16:22 GMT+01:00 Jeremy Evans:
>
>> Are you running the current version of Sequel?  I remember fixing an 
>> issue like this sometime in the past.  The line number you give doesn't 
>> really make sense to cause the issue in the current code.  If you are 
>> running the current version, please post a minimal self contained example 
>> showing the problem, and a full backtrace, and I should be able to debug.
>>
>
Thanks.  This does appear to be a bug, caused because the associations hash 
was frozen before validation (freeze validates), when it probably shouldn't 
be frozen until after.

This should fix it, I'll try to commit it tomorrow after more testing:

 diff --git a/lib/sequel/model/associations.rb 
b/lib/sequel/model/associations.rb
index 726bd2d8..8d6386d3 100644
--- a/lib/sequel/model/associations.rb
+++ b/lib/sequel/model/associations.rb
@@ -2119,8 +2119,10 @@ module Sequel
 # retrieving associations after freezing will still work in most 
cases,
 # but the associations will not be cached in the association cache.
 def freeze
-  associations.freeze
+  associations
   super
+  associations.freeze
+  self
 end

 private

You could work around this issue by overriding Company#freeze to call 
positions before calling super.

Thanks,
Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Migrations with sharded databases question

[Jay Danielian]

I've been able to successfuly setup my sharded databases and load records 
into it with my custom sharding scheme. So far I run 
Sequel::Migrator.apply(DB, './migrate') and it picks up my migration 
scripts. In my migration script I am doing this:

Sequel.migration do 
  up do 
DB.each_server do |db|
  db.create_table(:blah) ... 
   end 
end


And it works great - however I notice that the schema_info table is only in 
my :default database (the first shard if you will). Is this expected? My 
table is created with the proper schema in the "second" database shard, and 
read/writes work fine - so everything is working. Just curious if its 
expected to only write out the schema_info table on one of the databases.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: Object freeze and data reading

[David Espada]

2017-01-13 16:22 GMT+01:00 Jeremy Evans :

> Are you running the current version of Sequel?  I remember fixing an issue
> like this sometime in the past.  The line number you give doesn't really
> make sense to cause the issue in the current code.  If you are running the
> current version, please post a minimal self contained example showing the
> problem, and a full backtrace, and I should be able to debug.
>

Here it is:
>8
require 'sqlite3'
require 'sequel'

DB = Sequel.connect('sqlite://companies')

DB.create_table :companies do
  primary_key :id
  String :name
end
DB[:companies].insert(name: 'Acme')

DB.create_table :positions do
  primary_key :id
  String :name
  foreign_key :company_id, :companies
end
DB[:positions].insert(name: 'CEO', company_id: DB[:companies].first[:id])
DB[:positions].insert(name: 'CTO', company_id: DB[:companies].first[:id])

class Company < Sequel::Model
  one_to_many :positions

  def validate
super
errors.add(:bla) if positions.size > 2
  end
end

class Position < Sequel::Model
  many_to_one :company
end

c = Company.first
c.freeze
-->8

Greets.

-- 
David

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.