This example should give you an idea:

ruby-1.9.2-p180 :004 > me = User.find_by_email("[email protected]")
  UserAuthenticationIndex load (3.6ms)  find id(s): [email protected]
  User load (4.0ms)  find id(s): 1
 => #<User id: "1", birth_year: 1981, [.. attributes....] updated_at: "2011-05-18 10:33:42 +0200"> 
ruby-1.9.2-p180 :005 > me.birth_year = me.birth_year.to_s
 => "1981" 
ruby-1.9.2-p180 :009 > me.birth_year_changed?
 => true 

I think this should be evaluated as false.

It seems like the following code fails:

ruby-1.9.2-p0 > User.all.length
 => 1
ruby-1.9.2-p0 > User.all & User.all
 => [] 

As you expect something like this:

ruby-1.9.2-p0 > a = User.first
 => #<User id: "1", ...> 
ruby-1.9.2-p0 > [a] & [a]
 => [#<User id: "1", ...>] 

Seems to my like doing an atomic increment with a negative value works just as good as doing it with a positive one, thus we can implement atomic decrement in the Thrift adapter and in the ORM.

Seems like it does not. I think we should do that ;-) ...my bad.

In some situations when no records are persisted and references are being created and records are saved some records are not saved when you expect them to. For instance when a new record A references many Bs and you save your A, the Bs will not be automatically saved as it is now (if A was persisted then Bs will be persisted on assignment to A though.)

This might be implemented in a auto-save-module which uses callbacks or something and checks the relations and iterates over the records and saves them. We also might want to auto-check if all referenced records are valid before saving the parent.

Hi, I need to use references_many in my users model. When adding records, i run something like this:

interests.each do |i|
user.interests.<< UserInterest.create!( :id => MassiveRecord::ORM::IdFactory.next_for(UserInterest), :interest_key => i.id, :name => i.name )
end

in the user model I have : references_many :interests, :class_name => "UserInterest", :store_in => :info

So the UserInterest saves, and the ids appear in the interest_ids column in the User record. The problem is when I run user.interests, it returns an empty array.

Any Idea what I'm doing wrong?

For any ID requested, HBase will return the closest one. So, if we have 'ID1', 'ID2', 'ID3' and we request 'ID', we will get 'ID1' back. It shouldn't happened as it is a security issue.

Lets illustrate the current behavior with some example code:

class SuperClass < MassiveRecord::ORM::Table
  column_family :info do
    field :name
  end
end

class SubClass < SuperClass
  column_family :info do
    field :sub_class_attr
  end
end

class AnotherSubClass < SuperClass
  column_family :info do
    field :another_sub_class_attr
  end
end

In the example above all the classes will share the same schema definition (column families and fields). It might be better that sub-classes has a reference to it's parent's schema definition, but keeps it's own too. We most likely don't want AnotherSubClass to respond to sub_class_attr, and we don't want to end up with an InvalidColumnFamily telling us that a name has been taken if we define for instance attribute description in both SubClass' and AnotherSubClass' column family info.

Failures:

1. An event object should complain when given an invalid datetime
   Failure/Error: Event.make(:start_at => '99999').should have(1).error_on(:start_at)
   ArgumentError:
   invalid date

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/date.rb:1022:in `new_by_frags'

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/date.rb:1066:in`parse'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/bundler/gems/massive_record-12a03fea18de/lib/massive_record/orm/schema/field.rb:106:in `decode'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/bundler/gems/massive_record-12a03fea18de/lib/massive_record/orm/attribute_methods/read.rb:12:in`read_attribute'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/bundler/gems/massive_record-12a03fea18de/lib/massive_record/orm/attribute_methods/read.rb:18:in `attribute'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/attribute_methods.rb:276:in`start_at'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/errors.rb:218:in `block in add_on_blank'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/errors.rb:217:in`each'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/errors.rb:217:in `add_on_blank'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/validations/presence.rb:9:in`validate'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activesupport-3.0.3/lib/active_support/callbacks.rb:314:in `_callback_before_213'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activesupport-3.0.3/lib/active_support/callbacks.rb:419:in`_run_validate_callbacks'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/validations.rb:212:in `run_validations!'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/validations/callbacks.rb:67:in`block in run_validations!'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activesupport-3.0.3/lib/active_support/callbacks.rb:413:in `_run_validation_callbacks'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/validations/callbacks.rb:67:in`run_validations!'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/activemodel-3.0.3/lib/active_model/validations.rb:179:in `valid?'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-rails-2.4.1/lib/rspec/rails/extensions/active_record/base.rb:36:in`errors_on'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-expectations-2.4.0/lib/rspec/matchers/have.rb:20:in `matches?'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-expectations-2.4.0/lib/rspec/expectations/handler.rb:11:in`handle_matcher'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-expectations-2.4.0/lib/rspec/expectations/extensions/kernel.rb:27:in `should'

   ./spec/models/event_spec.rb:33:in`block (3 levels) in <top (required)>'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:49:in `instance_eval'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:49:in`block (2 levels) in run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:98:in `with_around_hooks'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:46:in`block in run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:91:in `block in with_pending_capture'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:90:in`catch'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:90:in `with_pending_capture'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example.rb:45:in`run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:261:in `block in run_examples'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:257:in`map'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:257:in `run_examples'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:231:in`run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:232:in `block in run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:232:in`map'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/example_group.rb:232:in `run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/command_line.rb:27:in`block (2 levels) in run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/command_line.rb:27:in `map'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/command_line.rb:27:in`block in run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/reporter.rb:12:in `report'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/core/command_line.rb:24:in`run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/rspec-core-2.4.0/lib/rspec/monkey/spork/test_framework/rspec.rb:4:in `run_tests'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/run_strategy/forking.rb:13:in`block in run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/forker.rb:21:in `block in initialize'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/forker.rb:18:in`fork'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/forker.rb:18:in `initialize'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/run_strategy/forking.rb:9:in`new'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/run_strategy/forking.rb:9:in `run'

   /Users/martins/.rvm/gems/ruby-1.9.2-p0@companybook-front/gems/spork-0.9.0.rc2/lib/spork/server.rb:47:in`run'

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1558:in `perform_without_block'

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1518:in`perform'

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1592:in `block (2 levels) in main_loop'

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1588:in`loop'

   /Users/martins/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1588:in `block in main_loop'

Finished in 0.87685 seconds
1 example, 1 failure

As we do not support find based on conditions (as many libs expects can be used for searching for records) we should raise an error on this case.

I don't think its 100% correct to store id in @attributes. I don't think ActiveRecord does it, and it for sure don't include id when attributes() are called.

We are doing some small hackish stuff when the ORM persists a nil-value. The value is ran through the coder and the returned string representation is what we are storing as value in Hbase. Attributes which are not yet persisted in the database, but are known to the schema will also be nil, and after digging a bit in the Thrift adapter it turns out to be really easy to delete a cell (when a value gets assigned nil). After we implement solve this issue we can no longer persist nil the old way; integers must either have a value or the cell can't be present if it is representing nil.

A column family collection might be better of implemented as a Set, and then implemen our own eql? method on column family objects compared on name so that the set will reject if we try to push two equal families on it.

An idea is to have read-method for ID to check for default_id() or something like that on new records so we don't have to explicitly set it on creation. A lot of use cases in hbase, the key is just a composite string defined from some of it's attributes arranged in some pre-defined way. So I guess it can be convenient to have something like that?

Title says it all, and Thorbjørn will fix it.

Title says it all :) It would be nice if we generate a class file for models when users generate resources via Rails' generators.

Seems like we have a problem related to timeouts on the connection. On the ORM::Base, connection is keept as a class variable and reused. If a server process is idle for some time we might end up with a IOError (closed stream). So, it needs to be solved by reconnecting I guess :-)

Use ActiveModel::Observer, look into how its implemented in ActiveRecord.

After doing Update.destroy_all I had one update left, which went away when I did Update.destroy_all again.

Right now its only possible to use strings for ids, which increase the size of the key when using integers etc.

According to birger thrift should support this, but if not - at least the java api does.

Because thrifts feature set is very limited

I need validates_presence_of to work with update only, but when I pass arguments to :on, the validations stop working completely

We should make time time zone aware, and should define a default time zone we will store time in database. By default it can be UTC. We should return time with zone CET if that is the application's time zone when reading time and date attributes from records, and we should persist them back in UTC.

Now, I really feel the urge to refactor how ColumnFamilies and it's
fields are maintained in the ORM. It's interface is hard to use unless
you use it via the default column_family :name do; ; end
construction in a class.

It feels bad for the following reasons:

1.  ORM-objects should have column_families like today, but it should
    return an object (a set) of column families. Not an array
    of ColumnFamilies which we have to loop over
    and detect to find one column. This new ColumnFamilies
    object should provide a simple interface to get-or-create-new column
    family given by name etc.
2.  Adding a field to an existing column family a hassle is today. The
    following is required and needs to be done manually every place you
    want to add a field to a family:
      1: Find (or create) your column family (detect on the
          column families array).
      2: Update ORM-object's attributes_schema hash to reflect new fields.
      3: Call undefine_attribute_methods to make write/read
          methods be regenerated.
    The responsibility for doing what needs to be done when a field is
    added to a column family should be done by the column family self.
3.  As mentioned in number two; attributes_schema, which now is a
    separate hash linking attributes to fields should be fetched from
    the ColumnFamilies object. As it is now, we need to maintain things
    more than one place, which is bad.

I know that it was written to be used with the following interface:
class Test < Table
column_family :info do
field :an_attribute
end
end

..but now we have two places which injects fields to families dynamically (IdFactory and Devise::Orm::MassiveRecord (glue for making MassiveRecord work with Devise)). Maybe I have the time to look at this soon :-) ..anyone having any other thoughts on this?

If nil is not allowed the field's default value should kick in.

colum_family :base do
  field :addresses, :array, :allow_nil => false # Will ensure that we'll always end up with an array
end

It is nice to have an identity map feature which caches records loaded from the database so that we don't load for instance the same user object twice. Seeing the debug output from an application using MassiveRecord might now give you (if you are not careful):
Started GET "/users/1/edit" for 127.0.0.1 at 2011-05-18 10:37:20 +0200
Processing by Users::UsersController#edit as HTML
Parameters: {"id"=>"1"}
User load (3.7ms) find id(s): 1
User load (4.4ms) find id(s): 1

It would be nice to get an object returned from the cache when calling User.find("1") the second time.

I vote for that we'll use next_id as a default id for records. The reason for this is that this code seems redundant. I say that is the default behavior, and that you switch it of by a configuration on ORM::Base if you want the old way - not doing anything automatically with the id assignment.

It is nice if we implemented use of atomic increment of fields. Seems like thrift supports this call via it's atomicIncrement().

So then we'll implement in the Persistence module an increment(attr_name, by = 1) and increment!(attr_name, by = 1) so we can call an_orm_object.increment(:an_attribute).

If you #save and #reload an instance that has an integer id, it will fail to find the row due to the fact that the returned id will be in string form.

Enforce string ID given that limitation?

If we have a class Person and a subclass Friend and we have only one person-record in our database and we do a Friend.first or Friend.all we'll get back that person object (as MassiveRecord currently only scans the table and return records instantiated with correct type).

It is really not that efficient, but I think we should make sure to reject Person objects when doing a Friend.first. It should return nil if only objects of class Person exists.

When a record is asked to be reloaded it should reset all of it's associations so that when making a call to an association it should be forced to reload these too from the database.

The auto loaded fields are associated to the class level, it means that it's never purged but aggregated. The autoload_fields option has been created to be used dynamically : with one instance I want this fields, and for another I want another fields. So the auto loaded fields should be associated within the instance.

Its important to be able to secure attributes stored via MassiveRecord in such a way that they can't be manipulated by injecting fields in to a form etc. Thus, we need attr_accessible / attr_protected functionality as you find it in ActiveRecord

Subscribe to notifications see this issue #32 and print out statistic about queries made to MassiveRecord's logger object.

Right now, when we ask Thirft adapter's row to do an atomic increment on a field we'll actually does not do it. We simply fetch value, increment it in the adapter-level and stores it back. This has been marked as fix me for a long time now, and I think we need to prioritize this.

I get the following warnings when running rails c

/usr/local/rvm/gems/ruby-1.8.7-p334@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/wrapper/cell.rb:41: warning: regexp has invalid interval
/usr/local/rvm/gems/ruby-1.8.7-p334@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/wrapper/cell.rb:41: warning: regexp has `}' without escape

probably just a typo somewhere

Using v0.1.1 btw

Currently we are storing the Fixnum 1 as the string "1" when it is being persisted. This has some bad implications like calling atomic increment on that value will not make any sense. So, this issue is related to this issue.

I think that we should raise a RecordNotUnique error if we have a row with id "1" and we try to save a new record with that same id. Right now I think the save will go through silently, and that we'll actually update the existing row with data from the new record.

At first we'll instrument strategic places like find and save. By doing this we'll be able to print out statistics to a logger, and enable users to freely to subscribe to internal events inside of MassiveRecord.

Have a look at the has_many branch, the methods and code is also already somewhere on CB

autoload_fields is String by default, it could be Hash, Integer etc.

Given you have a User models which references manyCars. If you do a User.first.cars.any? it will go ahead an fetch the complete collection and send the method call to the array of loaded cars. We can do better. If the foreign keys of cars are stored inside of the user we can simply check that array of ids without loading anything else from the database. If the foreign keys are not stored inside of the user's record we can internally make the proxy do a cars.first.present? when we make the User.first.cars.any? call.

We can also do this if you say User.first.cars.include?(Car.first) - we can simply check the local array of the user's car ids.

User.first.cars.length is also a method which we can optimize, reading the length from array of foreign keys.

I guess there are more examples; going through the proxy class might reveal more cases.

Hi,

When running any method that should read/write to Hbase (i.e. User.all ) I'm getting the following error:

NoMethodError: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.empty?
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/config.rb:17:in
connection' from /Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/persistence.rb:152:in ensure_that_we_have_table_and_column_families!'
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/persistence.rb:119:in
create' from /Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/callbacks.rb:44:in create'
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/activesupport-3.0.5/lib/active_support/callbacks.rb:420:in
_run_create_callbacks' from /Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/callbacks.rb:44:in create'
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/persistence.rb:115:in
create_or_update' from /Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/callbacks.rb:40:in create_or_update'
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/activesupport-3.0.5/lib/active_support/callbacks.rb:413:in
_run_save_callbacks' from /Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/callbacks.rb:40:in create_or_update'
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/persistence.rb:38:in
save' from /Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/attribute_methods/dirty.rb:10:in save'
from
/Users/jamiltao/.rvm/gems/ruby-1.8.7-p299@cj_pivot/gems/massive_record-0.1.1/lib/massive_record/orm/validations.rb:36:in
`save'
from (irb):14

I figured out that it was because :connection_configuration was coming up nil for some reason. I'm pretty sure I missed something somewhere, but i can't seem to figure out what I missed.

BTW, when I use MassiveRecord::Wrapper::Base.connection it works fine

Thanks!

Edit: Using v0.1.1

We have a small issue with MassiveRecord and Rails 3.1 (well, ActiveSupport::JSON that is). In the 3.0 series the JSON decoder used a YAML backend as default. Meaning that we could ask it to decode "1" and it would return the Fixnum 1. This no longer works as ActiveSupport::JSON now by default uses the JSON gem. It seems to be a bit stricter, and will not decode the "1" into a Fixnum.

So, we'll need to change our load/dump strategy a bit and make it a bit smarter not running simple types like fixnum via the coder.

When accessing a subclass from the parent class for the first time, attributes only found in the subclass are nil.
This happens because massiverecord hasn't loaded the subclass yet. On next calls the attributes are set.
So in production this should not be an issue.

Example:

class Vehicle < MassiveRecord::ORM::Table
  column_family :foo do
    field :type
  end
end

class Car < Vehicle
  column_family :bar do
    field :color
  end
end

rails console

Car.create :id => 'yaris' , :color => 'white'
reload!
Vehicle.first.color
=> nil
Vehicle.first.color
=> "white"

the exact error message im getting is:

private method `update' called for #HbaseUser:0x000001020872c8

It results in a thrift timeout error, if I remember correctly, which seems kinda strange for the end user if someone does a find(id).

Guess we don't want people to do a record.attributes.delete(:attr)? Added this as an issue so I'll remember it :-)