Astronomy 2.0

I've started this issue to share progress on Astronomy 2.0. I wanted to release RC version before the end of this year but it will be published in the beginning of the 2016. Originally, I wanted to finish the 1.0 version before the end of this year and now we have 1.2.x and I'm very close to publishing 2.0, so it's going quite well :).
I've rewritten almost entire package to make it faster (23 times faster document initialisation), less error prone and full-featured.
New features:

[x] ES2015 compatible
[x] Direct collection/class access (support for all MiniMongo modifiers)
[x] New events system
[x] Improved events propagation for nested classes
[x] Better error reporting on invalid schema
[x] New modules system
[x] Automatic document modifications detection. Now you can modify your documents freely without using set, push, inc etc. methods. Astronomy will detect changes to your documents and try to perform minimal query
[x] Save and remove methods implemented as Meteor methods. No need to create your own Meteor method to perform operation in both environments (client & server) - just call doc.save() or doc.remove()
[x] Validate document on every save
[x] Support for ObjectIDs
[ ] New validators system (partially implemented)
[ ] Named behaviors. Add multiple behaviors of the same type to the one class
[ ] Autoincrement fields
[ ] Built in relations module with ability to fetch/populate related documents
[ ] Mapping field name to different field name in collection

There are many new minor features that I will be adding to the list. There are also some changes to API about which I will be writing more soon. Astronomy 2.0 will also fix many bugs or problems from 1.0.

@jagi That is AWESOME man.
As you well know I'm a heavy user of your package (hence the multiple questions) and I'm super psyched to see what great changes you'll bring to this already great package.
Thanks for all your effort

Amazing. Thanks a lot for all this :+1:

Wow! Great!!

@jagi Amazing news !

That's great!! Thanks a lot!

I'm pretty excited about the relationships, built in methods, and modification stuff, great work!
FYI, Astronomy seems to work fine with react, have you thought about adding that to the docs? It would be interesting to know if there are any differences...  it seems like there wouldn't be, since Astronomy really just handles the backend.

Excellent!!! Great job, thank you!

Great job, we're quite excited about this :).
Have you considered an immutable option? Working with immutable objects makes it much easier to build performant React apps, because you can take advantage of shouldComponentUpdate with "===" comparisons (fast), instead of deep object comparisons (slow).
https://facebook.github.io/react/docs/advanced-performance.html
Right now:
var p1 = new Post(); // astronomy model called Post
var p2 = p1;
console.log(p1 === p2); // true

p1.set('name', 'different');
console.log(p1 === p2); // true

One example of a project that strikes a nice balance between immutable vs not immutable is https://github.com/Yomguithereal/baobab. Baobab is a state tree, that defaults to immutable, with an option to disable immutability.
It looks like Blaze2 will likely be built on React, and more and more Meteor users are using React, so it's something to consider.
Just food for thought! This is a sore point in our app right now, as it's difficult to optimize our re-renders when working with astronomy objects.

Another decent immutable reference:
https://github.com/hapijs/joi

Thank you all for good words :) I hope you will like changes I'm preparing :)
@JulianKingman it should work with React even better than 1.0, so yes I think that I will add proper information.
@marbemac as using the set method is not required in 2.0 to make changes to the model I think it's a good idea to create module to Astronomy 2.0 that would make astronomy document an immutable record. The only problem is that you have to use mutator methods. By default in Astronomy 2.0 we will have only one mutator method, which is set. However the module for React could provide more methods like push, slice, pop etc. and of course some method that could be used in the shouldComponentUpdate method doc.hasChanged('fieldName') or something like that.
To tell more about React... At the beginning, when I've heard that MDG wants to base future versions of Blaze on React I wan't happy. But after giving React a chance, I think that it's great, it can solve many problems and I will definitely support it in Astronomy. So any advices about features that could make this integration better are welcome :). And as Astronomy is modularised, then it will be very easy to develop some package/module called for example jagi:astronomy-react :)

@jagi Will there be an upgrade path from Astronomy 1 to 2? I'm starting a project and want to know if I should hold off integration Astronomy for now.

@sergiotapia 2.0 will not be compatible with 1.0 and projects made in 1.0 will need a few changes to work with 2.0. I will try to write upgrade guide as detailed as possible to make it smooth. If I were you I would wait for 2.0

Named behaviors. Add multiple behaviors of the same type to the one class
Do you have an example of how this would be defined?

Mapping field name to different field name in collection
This sounds like a great feature. Will this mapping be defined in the AstroClass like behaviors?

If you need help implementing these features, i could probably spare sometime. Let me know. Thanks!

@talha-asad

I have two ideas for API:

behaviors: {
  customNameA: {
    type: 'timestamp',
    options: {} /* optional */
  },
  customNameB: {
    type: 'timestamp',
    options: {} /* optional */
  }
}

behaviors: {
  timestamp: {
    /* optional options */
  },
  slug: [
    { /* optional options */ }, /* first behavior */
    { /* optional options */ } /* second behavior */
  ]
}

However, I will probably use the first approach. Because it will be easier to manage behaviors by name than by index and name.

Yes mapping will be defined next to the field definition.

Any help would be appreciated. However it may be hard to work on it for you as there is no documentation how it works internally and many thing have changed.
I will need help with validators and I will start new issue on github for that. I have a problem with choosing the right way of defining validators. I will tell more soon.

I like the first approach for behaviors as well, seems it is future-proof as well. Like potentially being able to supply more than options seems easier with that approach.
Whenever you create an issue like that, just mention me and hopefully i'll get along :+1:

I just saw this: https://github.com/jagi/meteor-astronomy/wiki/Feature-Requests
Are we going to have ENUM support in Astro 2.0?
Doesn't seem to be in your todo list.

It's not a top priority, so for now I'm not planning to do it in the first release but if there will be enough time I will implement it.

Currently in Astronomy 1.0 we don't get .aggregate method on astronomy classes even after adding meteorhacks:aggregate Is this something you plan on fixing in 2.0?

#265

Astronomy class is astronomy class, and Mongo Collection is Mongo Collection. Adding meteorhacks:aggregate does not change here anything. It just adds the aggregate method to all collections. It's also worth noticing that it only work on the server. I'm not going to support aggregate operation until it's officially supported by Meteor.

agree with @jagi ...
meteorhacks:aggregate work with me,, you should using Collection instead of Class...
if you want to support aggregation with Astronomy,,, maybe better to create module....

I've published 2.0.0-rc.1 version of Astronomy. It still lacks of some features but I've decided to publish it anyway. There will be a few changes in behaviors and indexes modules that can cause API to be changed. To add Astronomy 2.0.0-rc.1 to your project just type in the console:
meteor add<EMAIL_ADDRESS>
The best way to learn about the API (as there is no documentation yet) is by taking a look at this example.
Behaviors for Astronomy 2.0 are not yet published.

Congrats on releasing rc1 :+1:

Great, I'm going to test it asap :+1:

I see that next in the checklist is

Named behaviors. Add multiple behaviors of the same type to the one class

Are these behaviours also going to work for nested objects?
One a side-note, i think the real spelling of behavior are "behaviour". But maybe i am wrong lol.

Yes behaviors should work on nested objects but probable not in all use cases we're discussing here on GitHub. I will tell more when I will be working on it.
behaviors and behaviours are both correct behaviors is American English and behaviours is British English https://www.diki.pl/slownik-angielskiego?q=behavior

:rocket: Awesome stuff, I'm use Astronomy 1 in my project. When do you think 2 is going to land for production use? I'd rather update sooner rather than later. when my models are few.

It's hard to tell when it's going to be released. I have a lot of work to do also beside my regular work and Astronomy. On the other hand I have to release it as soon as possible because we will be using Astronomy 2.0 in our products at Useful IO. So the pressure is quite high. It will definitely be Q1.

Cool stuff, we're really excited to try it out here on our large Meteor app. Astronomy feels really natural to use in a Meteor app, should be brought into core.

Starting to adapt my models using RC1, we will definitely want to use it as soon as possible so keep up the good work :)
One issue I can't seem to solve without documentation is declaring a field as a 'blackbox' Object.  Allowing any sort of object to be put into a field.
If I use type: Object  I get "Type of the field has to be scalar, class, list of scalars or list of classes"
Is this going to be possible with 2.0?

@willrbc I haven't decided yet if it will be possible. For now it's not because I've decided to be compatible with GraphQL in which you have to declare types for each field. Probably it could be possible by creating custom type which is also possible in GraphQL. For now I would like to know as many use cases as possible to get know if such feature is needed at all.

We absolutely need to be define objects without defining their schemas. This useful because:
a) We don't necessarily want to define astronomy objects for every single property all the way into our nested models.
b) Mongo is great for storing arbitrary objects, and requiring us to define, upfront, every property in every model means we can't take advantage of this.
For example, we store http request/response data in one of our models, and the response bodies can be json objects of any format.

I will probably introduce Object type where it will be any JSON object. However when talking about "any" type or "lack of type" I think it can be avoided.

Yup that's perfect.

It's been a little while since I looked at GraphQL, but my sense is that when creating custom object types, you still wind up explicitly defining things all the way down to scalar leaf nodes... so not sure how easy that will be to allow fuzzy areas in the schema and still keep it GraphQL-friendly.

Perhaps leave it up to the user to define objects in their totality if they're using astronomy with graphql? You could even log out optional warnings when the user tries to combine generic objects and graphql

Yeah, maybe you could 'opt out' of a strictly GraphQL-friendly and instrospectable default at the schema level, similar to the case of having 'required' as a default.  You could still be partially compliant, but control whether errors are thrown as you suggest.

That works. In general, graphql is still an area of great thought and change in the Meteor community. I would suggest designing astronomy v2 with an eye towards possible graphql support in the future, but not get too bogged down on it now.

Thanks,  I agree with @marbemac,  a JSON object is all we need.  That would give us the flexibility we need.  At the moment I need to create an Object field called Legacy which I can store an assortment of info from data imported from a legacy SQL database, (such as identity fields of related data etc).  Realistically I could define all the fields I need for this but I didn't as it's an edge use case, more needed for testing / development than production.

I agree with @marbemac too. Support for arbitrary objects should be allowed. The disadvantage being that class maybe doesn't get GraphQL support.

I will allow the Object type and it should work with GraphQL as well. I've consulted it with @ianserlin and GraphQL is only used to fetch data. It does not care about database structure. So it a job for the resolver to provide data in a format that user is requesting. So it won't be a problem to allow any JSON data for a field.

Ah, so Astro and the GraphQL layers will still be well separated.  No problem then :).

json object would be great..!!
i have linkedin http call to retrieve user information,,, the fields is dynamic depend on user,,, so i don't know how to store into collection since i have to define the fields... astro json object could be the solution...
thank You so much for providing it.... =))

I've released 2.0.0-rc.2.
Here is a list of new things:

Added validators from 1.0: choice, equal, regexp, object
Added Object type for storing any JSON object
Introduced the resolve field's property to allow fields mapping (it's works similarly to GraphQL)

fields: {
  firstName: {
    type: String,
    resolve: function(doc) {
      return doc.lastName; // Don't make sense but it's just to illustrate how it work :)
    }
  }
}

List of changes:

Now it's not possible to do something like this:

new User({
  'address.city': 'San Francisco'
});

Instead, you should do something like this:
var u = new User();
u.set({
  'address.city': 'San Francisco'
});

In fact using class constructor to initialize document shouldn't be overused. It's mostly used by the find() method.
I haven't done a lot this week. But in the following week I will try to do more.

Congratulations!
Can you share a bit more about why you wouldn't want to pass objects to the class constructor, or what we should do instead of using the class constructor altogether?

Congrats Jagi, this is going so well I would not be surprised if it's merged into Meteor core. The missing data layer.

@ianserlin ok, so let me give more background on that.
I've done that because of the resolve function which I've introduced. Here is what I do in the constructor:
let fields = Class.getFields();
_.each(fields, function(field) {
	doc[field.name] = field.resolveValue(plainDoc);
});

I'm using the resolveValue method for each registered field in the schema. So constructions like address.city would not work. However, as I'm thinking about it right now I could move this code to the find() method where the resolver should actually be executed. Hmm I will probably change that.
@sergiotapia I don't think that MDG is going to merge any external package into core but from what I've heard they gonna be working on the "data layer" soon so as Sasho Stubailo said they will contact me and Aldeed to talk about data layer.

I've published 2.0.0-rc.3 with minor changes:

Introduced e.trusted property in before/after save, insert, update, remove events which determines if the save/remove method call was invoked from the client (untrusted) or server (trusted)
Now it's possible to turn of document transformation in Class.find(selector, {transform: null});
Limit amount of data passed to the server on document update in when calling doc.save();

and I've done little cleaning of the old code.
More new stuff to come.

:fire: Getting closer and closer... :rocket:

@jagi thank you!

@sergiotapia yep :)
@ianserlin no problem :)

I've introduced bug in 2.0.0-rc.3 so I had to fix it and add more tests (because of bad tests I haven't noticed it). So I've published 2.0.0-rc.4. Sorry for that. I hope it won't be 2.0.0-rc.99 until 2.0.0 release :D

I have a question to all of you about events. It's related with the timestamp behavior. The question:

Should the beforeSave/beforeUpdate events be always triggered on the doc.save() execution or when there are any changes to be saved (document is modified).

Now I will give some details, why I need answer to these questions. I think that these events should only be triggered when there is actual save happening (document is modified - there is anything to be saved).
Let's say we have the following code:
var doc = Doc.findOne();
doc.save();

We haven't modified anything but both beforeSave and beforeUpdate events will be triggered. Now in the timestamp behavior I will need to check if there are any modifications and only set the updatedAt field when needed.
Now, let's say that we won't trigger these events until we do something like this:
var doc = Doc.findOne();
doc.name = 'New name';
doc.save();

So, only when we make any change the beforeSave and beforeUpdate events will be called. In such situation in the timestamp behavior, we don't need to check anything.
So what do you think. I think the second approach is correct and it shouldn't cause any problems. Please, try thinking if such change would make any difference to your existing applications. In Astronomy 1.0 the first solution is used. And for now in Astronomy I'm also using it. But I want to switch to the second one, which seems to be for me more appropriate.
What do you think?

I believe only when document is changed.
Sent from my iPhone

On Feb 6, 2016, at 6:41 PM, jagi<EMAIL_ADDRESS>wrote:
I have a question to all of you about events. It's related with the timestamp behavior. The question:
Should the beforeSave/beforeUpdate events be always triggered on the doc.save() execution or when there are any changes to be saved (document is modified).
Now I will give some details, why I need answer to these questions. I think that these events should only be triggered when there is actual save happening (document is modified - there is anything to be saved).
Let's say we have the following code:
var doc = Doc.findOne();
doc.save();
We haven't modified anything but both beforeSave and beforeUpdate events will be triggered. Now in the timestamp behavior I will need to check if there are any modifications and only set the updatedAt field when needed.
Now, let's say that we won't trigger these events until we do something like this:
var doc = Doc.findOne();
doc.name = 'New name';
doc.save();
So, only when we make any change the beforeSave and beforeUpdate events will be called. In such situation in the timestamp behavior, we don't need to check anything.
So what do you think. I think the second approach is correct and it shouldn't cause any problems. Please, try thinking if such change would make any difference to your existing applications. In Astronomy 1.0 the first solution is used. And for now in Astronomy I'm also using it. But I want to switch to the second one, which seems to be for me more appropriate.
What do you think?
—
Reply to this email directly or view it on GitHub.

Only when the document is changed, and a save actually happens. This is the way most frameworks work.
No worries about the rc4, Meteor 1.3 is already at 8 :). Take your time!

What about:
var doc = new Doc();
doc.save();

Would it trigger the events if there are default fields defined for the schema? Would it trigger the events if there are no default fields simply because it has generated an _id? If so, then I think case 2 is reasonable.

Basic rule of thumb:
If the document is being persisted to the DB, I would expect the save callbacks to be run.
If the document is being persisted to the DB, and is new (ie this is an insert), I would expect the create callbacks to also be run.
So yes, in the case you describe above, hooks are normally run (since it results in a write to the db).

Thanks for feedback! Yes, it will trigger events on document insertion.
var doc = new Doc();
doc.save();

This will trigger following events: beforeSave, beforeInsert and if there was no validation error also: afterInsert and afterSave.
var doc = Doc.findOne();
doc.save();

This won't trigger any events.
var doc = Doc.findOne();
doc.name = 'new name';
doc.save();

This will trigger: beforeSave and beforeUpdate events and afterUpdate and afterSave if there was no validation error.
So I will implement it that way. Thanks!

That makes sense.

Hi @jagi, to clarify your previous post.
Is it aware of previous content? For example:
var doc = Doc.findOne(); doc.name = 'Some name' //doc.name was already Some name, it has been set again but not changed doc.save();
Name hasn't changed as it has been set by some code to be the same as it already was.  Would this trigger events?

@willrbc in such situation it wouldn't trigger any events as there were no modifications.

There is an another problem. This time I need discussion about the change event. It's not already implemented and I'm working on it. However, I'm considering not implementing it at all. Let me give a little bit more background.
The change event is closely related with the getModified method. The getModified method is getting RAW values from the current document and a document before modification and is comparing them. It will try to create a list of fields that have changed and this list should be as minimal as possible. It's especially important if it goes about arrays of values, where we don't want to override entire array but only add or remove values that have changed.
Now more about the change event or maybe set of events: valueChange, valueAdded, valueRemoved. When we register the valueChange event on the level of top class (let's say the User class from the example app), we should receive information about the value change of every field. If we register the valueAdded event on the level of top Class (User), we should receive information about every phone object added to the list of phones as well the information about the change of the phones field.
Right now the getModified method returns only changed and added values. So, if we have for example array: numbers: [1, 2, 3, 4] and we add new number numbers: [1, 2, 3, 4, 5] will receive information about a change numbers.4 = 5. Which is ok, but when we remove an element numbers: [1, 2, 3] we will receive the following information about the change numbers: [1, 2, 3]. So, entire numbers array will be overridden what of course is not optimal solution. So to solve that problem I have to change the way how the getModified method works. Instead of just returning fields that have change it will return object of the following structure:
doc.getModified();
{
  changed: {},
  added: {},
  removed: {}
}

And the first question is: Is it ok to change the way how the getModified method work?
The second problem is the Object type which can be any structure, we want. And it's much more complex. Let's say that in the User class we have the any field of the Object type. We can implement the getModified method for the Object type in two ways easy and hard. Easy one is just overriding entire field value on every change. The hard way is doing checks for every nested field of the any field. However, every change event would be send to the User object. The question is which solution should I implement, the easy one or the hard one?
We also have to answer the question: Do we need the change event at all?
Actually, when writing this post everything got organised in my mind and I have a few ideas how to solve my problems but I still would like to here your opinion and maybe some suggestions.

Hmm, interesting questions. My two cents, based on working with astronomy for the API designer over at stoplight.io.
Change events
I personally think the change events are overkill. There are many other, mature ways, to watch for changes to state.
getModified structure
I don't mind this sort of change. To me, the most important factor here is choosing the underlying implementation that will result in the most stable DB updates, with the least complexity. This is a major point release - updating the getModified return signature is nbd. For our purposes, we don't even mind if the updates aren't perfectly "minimum". Ie, set the whole array if it means #156 goes away - that issue is causing all sorts of issues right now.
I'm not sure I understand that last issue with the Object type and getModified. Could you elaborate a little bit?

Change events
Personally I never use the change event. And yes there are many ways of checking if a field's value has changed. One solution could be something like this:
beforeSave: function(e) {
  var doc = e.target;
  var original = User.findOne(doc._id);
  if (doc.firstName !== original.firstName) {
    // First name has changed
  }
}

So maybe you're right that it's overkill. It won't be used very often and it can introduce many bugs.
getModified structure
You know it's hard (if not impossible) to create a query that will be optimal in all cases. So it will only be approximation which in most cases will be optimal (when setting values and adding array elements). But if user will modify an array by adding and removing many elements, then the only way of performing a query will be just overriding entire array. We can quite easily detect addition to array and removals of elements residing at the end. For other situations I will have to replace entire array. And that's how it works right now.
Object type
The problem with the object type is that it does not have fields definition so we have to make regular JS diff on two objects to look for changes. However, I can use the same diff tool I have for defined fields' types. The only problem is the change event that would have to be triggered on the top level class.
SUMMARY
As I think about it right now, I think that maybe it's not a good idea to introduce the change event at all. I will wait for more comments but right now I'm like 99% sure that it's not necessary.
Thanks!

True, but change events aren't even about checking to see if a value has changed (that's getModified()). They're used to listen and react to WHEN a value is changed. Curious to see what others think - but I agree, limited value.
Totally agree on the getModified issue, and what I was trying to get at. It's a balancing act between introducing complexity, and covering every single edge case trying to build optimal updates. If mutations can be mostly optimal, while minimizing complexity / potential for bugs, that's great.
For the object type, regular diffing makes sense :). Or even just the _.isEqual lodash (or underscore if it has that?) method.

I would even modify how the getModified method work in the following way:
user.getModified(); // returns ['firstName', 'address', 'addess.city', 'phones', 'phones.0', 'phones.0.number']

to return only list of the modified fields. In most situations the most important information is that a field value has changed. And we can do something like this if we need more information:
events: {
	beforeSave: function(e) {
		let doc = e.target;
		if (doc.isModified('address.city')) {
			let value = doc.get('address.city');
			// Do something with the value...

			// Get original value.
			let oldDoc = User.findOne(doc._id);
			let oldValue = oldDoc.get('address.city');
		}
	}
}

The isModified method is just checking if a given field name (field pattern) exists in the list of modified fields.
If it goes about the Object type I was thinking about a diff not checking equality. Of course I could override entire field value and check differences using EJSON.equals. But I would like to detect changes on the level of subfields. And that's exactly what I'm gonna do :)

+1 That all sounds good to me!

Jagi, I really appreciate all the effort you are putting in.

@marbemac ok good :)
@talha-asad :) I like what I do and hearing good words from community is always uplifting

Yeah you're building what I feel is a fundamental missing part of Meteor. :rocket:

I've published<EMAIL_ADDRESS>that works with<EMAIL_ADDRESS>New behaviors system is not ready yet, so it's working the old.

I've published<EMAIL_ADDRESS>with new modules system that allows multiple behaviors of the same type per one class. I've also updated timestamp behavior to<EMAIL_ADDRESS>Tomorrow I will update the slug behavior to work with the new system.
To tell more about multiple behaviors of the same type. You can still define behaviors in the old way:
behaviors: ['timestamp', 'slug']
// or
behaviors: {
  timestamp: {
    hasUpdatedField: false
  },
  slug: {}
}

However, if you want multiple timestamp behaviors you have to provide array of options.
behaviors: {
  timestamp: [
    { createdFieldName: 'created_at', updatedFieldName: 'updated_at' },
    {} // Use default set of options.
  ]
}

It's getting awesome :)
Astronomy 2 has a way of declaring a static methods?

Thanks :). No it doesn't, but it's possible by just adding methods to already created class constructor. However, such methods won't be inherited by child classes. There is a way of achieving inheritance but it won't work in all browsers.

Thanks @jagi, it's just to organize the code around a model class, i don't have the need for inheritance now.

I would recommend keeping as much logic as possible OUT of astronomy classes. We organize everything as plain old javascript functions, and call these functions as necessary from astronomy class events, etc. You'll find that it's easier to re-use, and test, these functions, if the logic is not all interspersed in astronomy models.

Just found Astronomy yesterday, have read over 1.x docs (hugely helpful), skimmed source, tinkered with some code, and gotten caught up with the great conversations re Astronomy here and on the meteor forums. Bravo to @jagi, first off, and thanks for all the effort!
I'm in the process now of learning the ways of meteor and MongoDB, with the goal of building V2 of a huge PHP/Symfony/Doctrine project in meteor. Astronomy looks to be a wonderful fit—I gather I must take care not to use its functionality as a crutch and debase Mongo by making it behave like a poor-man's RDBMS ;).
My conundrum is this: I'm about ready to start coding for real, but being new to meteor, I'm torn between diving in with Astronomy v2RC (sans-documentation) and using V1 to get off the ground, then refactoring when V2 drops and @jagi, et. all get some documentation up for it. In a nutshell, I'm wondering how big a hurdle lacking documentation will be at my point on the learning curve. Any thoughts (from anyone in this thread)?

@dtwist I've updated the first post in this thread with details about changes in v2. Many people are asking about this so I've decided to write short summary. The good source of knowledge is also example application that was rewritten to use v2. I think it's a good time to start developing in v2 as it's quite stable and there won't be probably any breaking changes - only improvements and new features. It's not so far from releasing v2.
So if you want to use Astronomy I would first encourage you to read through the documentation for v1 and just use new syntax from v2. The main principles in Astronomy haven't changed much (only saving and validation have changed).
I hope you will like it :).
@fabiodr For now I won't implement static methods as it's quite easy to add them just to the class constructor. Maybe in the future in some of 2.x releases. For now there are more important things :)

@jagi Thanks for the quick reply. I've read the docs for 1.0 from top to bottom, and they're very helpful. I had thought that the notes above re V2 were more high-level. If they really represent the core differences then fabulous; I'll dive in. :)
btw, The example app demo is currently broken (Can't add new users). :/
Looking forward to using Astronomy. :)

@dtwist no problem :)
It works, I've just added new user. You are probably getting validation are because of some fields missing. Try filling all the required fields and in the correct format.

Was trying the V2 example app, but it gives this error:
   error: Potentially incompatible change required to top-level dependency: jagi:astronomy 1.2.10, was 2.0.0-rc.1.
   Constraints on package "jagi:astronomy":
   *<EMAIL_ADDRESS><- jagi:astronomy-timestamp-behavior 1.1.0

@sanderdatema You have to update jagi:astronomy-timestamp-behavior to 2.0.0-rc.2

Thanks. Is there any chance you'll move to a more recent version of lodash? Some other packages need the newer version.

Yes sure, when I was moving to lodash from underscore it was still 3.x version, and now it's 4.5. So I will update with the next RC version.

little offtopic question
How is the compatibility status of v2 with Meteor 1.3? I know neither were released yet, but I'm about to start a new project and I'm thinking of adopting all the new stuff that is about to come out so I don't have to update anything later on.

I should work with Meteor 1.3 without any problems ad Meteor 1.3 is backward compatible with 1.2. However, I will test it to make sure before releasing Astro 2.0

@jagi That's awesome man! Do we have an ETA or something? Just so I know which version to pick (:

I estimated that I will finish it until the end of Q1 and I will do all I can to deliver it until that time. I have 2 weeks of holidays at the end of March and I hope that it will not cause me to postpone premiere by 2 weeks. The problem is that Astro 2.0 requires new documentation and I don't want to release it without docs.

@lsunsi Hold your horses then. :) I was justing trying out Astronomy 2.0 with Meteor 1.3 and got this error:
=> Errors prevented startup:
   While processing files with ecmascript (for target web.browser):
   jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super() outside of class constructor (10:4)
   jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super() outside of class constructor (10:4)
   jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside of class constructor (12:2)

Hmm strange, maybe they updated ecmascript package to use the newest version of bablejs that has changed something. But from what I know it correct way of the super keyword usage. I will check it out :)

Yes in deed there is a bug in Astronomy but it's strange that it worked in 1.2. I've fixed it and will release it soon.

Yes, Astronomy 1.2 does work fine with Meteor 1.3. Odd...

@jagi Yeah man, that's awesome. When it is out, whenever it is, I'll be using it in all my meteor products. Thanks man!

@sanderdatema Yeah, just got the same error. Weird, huh? Wasn't expecting a ecmascript error

The problem was Loose mode in babeljs. It allows different syntax depending on if it's on or off. And apparently it has changed in updated version of ecmascript package. I've already updated that in Astronomy 2.0 and it will work with Meteor 1.3 in the next RC release.

@jagi that was fast haha (:

Maybe this is off topic. Is Astronomy compatible with Mantra and is it compatible with React Native.

Since Astronomy is using modules, will I have to do something like
import { Astro } from 'where';
where ever I define Astro classes?

@smooJitter
Astronomy 2.0 is not using ES2015 modules so you don't have to use import to load Astro global. Modules system in Astronomy is just a term to describe modularity of Astronomy. It's easy to write new features for Astronomy in form of modules.
I don't know if it's compatible with Mantra or React Native as I haven't used them. It should be compatible with React Native as it's only view layer and Astronomy is not dependent on any view layer. If it goes about Mantra, from what I know it's just set of tools and good practices so it shouldn't interfere with Astronomy.

Jagi please state the latest rc version on the first post in this issue, I think it will alot of users.

@talha-asad yes sure!
@smooJitter I will actually use ES2015 modules in the next RC version. I'm already rewriting it. It will make code much cleaner. From what I know there are two possible solutions for package inclusion. I can make it only ES2015 modules compatible and it would require:
import Astro from 'meteor/jagi:astronomy'

or
// somewhere in the first project file being loaded
Astro = Package['jagi:astronomy'].Astro;

Or I can do it the old way and export the Astro global variable.

@jagi Maybe you should do both ways, is that possible?
For instance, I think kadira is implementing it in both ways in his most popular packages like FlowRouter.
I can be wrong though.

@lsunsi Hmmm I don't think it's possible both ways. You can export some variable to the global scope or import variables into a given file. Of course you can import variable anyway but what's the point if it's already in the global scope?

@jagi yeah, I get what you mean, you're probably right. The point is to make a modular application without a global scope :p like only importing in some app application context like suggested in mantra

@lsunsi I've updated my previous comment so take a look at it.
Yes modularity is a great thing. And I didn't want to use ES2015 modules for now in Astronomy but after playing with it for a while I see many advantages. My code got simplified.

@jagi yeah, we are definitely on the same page man. I'm play around with 1.3 plus Mantra and the ES2015 modules look great

After upgrading to rc-5. There is no upsert function available on the Astro class. Is this by design? Can i use rawCollection and then call the upsert function?

@talha-asad Yes it will be back in 2.0.rc.* :). In fact in Meteor the upsert method is just the update method but with some extra options so it's not a big deal.

So right now if I do this:
let campaignObj = new Campaign(plainCampaignObj);
campaignObj.save();

Here Campaign is an Astro Class.
Will this way update an existing document, if plainCampaignObj has an _id present and insert a new one if not?

To make it work you have to:
let campaignObj = new Campaign(plainCampaignObj);
campaignObj._isNew = false;
campaignObj.save();

Thanks, awesome hack. :+1:

Perhaps this could be exposed as a standard utility function to change behaviour from insertion to updation, instead of using a _property.

Yes I thought about something like doc.status('new') or doc.status(Astro.Class.STATUS_NEW) or doc.isNew(true) or anything that would make sense. I agree that change _property value seems to be hacky but I will think about better solution. Or you can propose your syntax.

Some suggestions:
doc.markNew(true);
doc.isNew(true);

I would not recommend using doc.status because it will probably be a commonly used key in docs.

Thanks for the clarification.  Regarding React Native I believe the issue is minimogo and tracker isn't readily available. The following package addresses this gap, https://github.com/petehunt/minimongo-cache but I'm not sure where Astronomy relates. I'm thoughts were to construct Astro classes that update buy calling actions that reference method-hooks.   This brings up another issue, suppose I'd like to allow mongodb to generate _id values, should I adopt a simular work around ( doc.IsNew(false) )?  After 2.0 release, and considering the impact of React, it maybe worth thinking about or illustrating how Astronomy interacts with various client-side state management frameworks (redux, flux).
PS the Mantra Kickstarter repo uses Astronomy but it does so in a way that doesn't really seem to jive with Mantra guild lines. Essentially, it isn't clear how Astro gets passed through props and dependency injections. I'm a newbie, I wish I knew knew enough to contribute by clearing some of this up because I do thing the community would appreciate seeing how Astronomy plays with emerging view layers

saveAsNew()?

@zimt28 it's not about saving a document as a new. It will save document as a new even if there is the _id field set. It's about changing document's status. And I agree that doc.status() may not be the best idea. I will figure something out.

From zimt28's solution we could have doc.save() and doc.update()

@jagi in V2, are there events that give me the previous value before it is changed? I don't see the e.data object in the beforeChange event anymore. Thanks :)

@tjscooper no there is no change event. I've decided no to introduce it. It's not needed to do what you could do in v1. Let's say you have the beforeSave event.
// User class
beforeSave: function(e) {
  let doc = e.target;
  let originalDoc = User.findOne(doc._id);
  if (originalDoc.firstName !== doc.firstName) {
  }
}

I know that it's more work to do but it's more flexible. There was also a change in the getModified() method which now returns fields names that was modified - not values. However I'm considering introducing the getModifiedValues(old) method.

I'm thinking of the possibility of adding the feature of saving the document bypassing the validation.
The use case that I have is that I have a big form that breaks into multiple pages. I don't want to intimidate the users, so the every page saves a portion of the document. Set all the fields as optional or have a bunch of Validators.if could technically solve the problem, but both approaches incurs some inconvenience in other features too.
So I'm thinking if it makes sense to have an option argument adding to the save method, something like doc.save({ validation: false }) that is only exposed on the server side. And people can choose to bypass the validation or do partial validation in the trusted environment.
What do you think on this one?

Oh I realized that we could do things like user.save(['firstName', 'lastName']);. I haven't tested it out in 2.0 yet. But will this action trigger the full document validation or just these two fields? I guess in this case we still need full document validation by default because validators on other fields might depend on values of these two fields. And then the comment above is still valid.

@minfawang I've removed this argument from the save method as it does not keep integrity of a document. We can't save partial document. Of course I understand that there are some cases that requires partial saving. What I can propose is to use the validate method to validate certain fields but save a document using standard collection. Here how to do it:
var fields = ['firstName', 'lastName'];
var user = new User();
// ... set some fields values ...
user.validate(fields, function(err) {
  // The validate method is calling meteor method to perform validation also on the server.
  if (!err) {
    var rawValues = user.raw(fields);
    Users.update(user._id, { $set: rawValues });
  }
});

Oh that looks to be a pretty good solution! I'm happy with this solution.
Looks like the validate function is now uses Meteor methods internally too and takes the can take callback function as parameter. It's also really neat! I was writing a custom behavior in 1.x to achieve the same effect.

@minfawang Yes it's using meteor method the same way as save and remove methods :). In 1.x you have to write custom methods for that. So I think it will speed up development :)

Absolutely! Thank you for the awesome work!!

Does that mean that mean 2.0 will call a predefined method on the server when calling .save() on the client? Can I change them somehow? Im not using allow/ deny rules, so I'd like to have some permission checks in my methods.

@zimt28 Starting in v2 when .save() is called on the client, all the beforeSave/Insert/Update/Remove and afterSave/Insert/Update/Remove hooks are also run on the server-side.
What we've done is inject our auth logic inside these beforeSave/Insert/Update/Remove (either directly or by calling another function). If your auth check fails, then you can throw an error in the beforeSave/Insert/Update/Remove hook or return false to prevent the save.
Finally, in the most recent rc.x versions the event that you receive in the hooks have a trusted property which lets you determine on the server if the request to save/update/remove the document originated from client (browser) code or your server-side code. That let's you do something like:
Astro.Class.create({
     name: 'Car'
 ...
, events: {
     beforeInsert: [
         function checkUserID (e) {
              var car = e.currentTarget;
              if(!e.trusted){
                    // run security checks
                    if( /* check doesn't pass */ ){
                          throw new Meteor.Error("not-allowed", "You don't have sufficient permissions to create a car.");
                    }
              }
              // request to insert came from server-code, explicitly trust
         }
         , function checkSomethingICareAbout (e) {
            // ... some other kind of check, possibly using `e.trusted` to determine if we need to run the check
         }
     ]
 }
});

@ianserlin thanks for help :)
Moreover I will probably allow disabling autocalling meteor method when saving, removing or validating. There can be some edge cases when it's not expected to happen. I'm not sure what API for that will look like. If it should be done per class or per method call (I'm for method call)

Is there a way to add more methods to a class after it's initialization?

@talha-asad Yes it works the same way as in Astronomy 1.x:
Class.extend({
  methods: {
    newMethod: function() {
      /* ... */
    }
  }
});

@jagi Thanks this is an awesome option. Didn't knew it existed.

@talha-asad Every thing is in the documentation ;-)
I won't mess with the save() method for state changes as it does not the point. It's not about the save method it's about the state of document. It may not necessarily be related with saving. You may need changing document state regardless of that. So it will be something different.

Makes sense. Thanks :+1:

Back to the validation topic. It looks like if I do validation on the client side, and the document passes the client side validation, it will always go to do the server side validation.
There are use cases like continuous form validation, where the validate function is called very frequently. Most validators (except for those checking for uniqueness) don't require to run on the server to get correct result. Maybe it will make sense to have an option to do client-only validation? It's more like an optimization than an issue.

@minfawang yes in deed. I know about that and I have idea how to solve it. The same is true about save and remove methods. There should be an option to call given method only on the client.

@jagi Sounds great!

@jagi Can we look at the relations already? Laravel's Eloquent Relations are quite nice, it would be cool to have something powerful for Meteor.
Will things like Post.find({ _id: postId }).comments().insert(comment) be possible? This would basically have to add a postId, or any other key specified to the comment. Or are things more complicated than I'm assuming? :)

@zimt28 such syntax won't be possible. post.comments() would actually return an array of documents instead of some object with the insert method. It has to be done that way because of need to loop through the comments in a template.
{{#each post.comments}}
{{/each}}

I have to postpone relations module to Astronomy 2.1. I will release 2.0 without relations. There are several reasons for doing so. My development ability slowed down lately and I want to release 2.0 before the end of Q1. There are still several issues related with validation. I'm also working with @aldeed on common pattern for validation in SimpleSchema and Astronomy. That would allow package like Autoform to be used with Astronomy in certain circumstances.
So I don't want to put to much features in this release. Relations module is a lot of work and I want to make it right. And there is documentation that has to be written. So a lot of stuff to do.

Well, it would simply be  post.comments().find(query) in that case, which would simply add the postId to the query.
{{#each post.comments.find}}
{{/each}}

This would still work, but in most cases people will want to filter collections, instead of showing all the items. So they will use helpers anyway, where they're used to .find() syntax.

Quick example: https://gist.github.com/zimt28/ccb3b2b184bc7eaec22f

@zimt28 Oh I see. I like this idea. Hmm I would like to see more opinions on such approach but in deed it may be nice.

Yes, me too :) I just feel like things are not too hard to implement, and can be very powerful.
So if someone is interested in relations, please give some feedback:
https://gist.github.com/zimt28/9cfc0f76118a77d37d2a#file-relations-hasmany-js-L4-L35

I think it's very intuitive, although Astronomy replaces .insert() and update() with `````.set()and.save()````, right?
Also, I don't want to derail the conversation, but this made me think of another question: will .save() be synchronous, since it will run on both client and server? Right now, calling it with a method makes it asynchronous, which causes problems in synchronous loops (basically, I can't use them and have to call synchronous loops that use update/insert instead)

@JulianKingman in Astronomy 2.0 there is the doc.save() method but also Class.insert() and Class.update() for "direct collection access". When you call doc.save() it will perform operation on the client and server and response from the server is always asynchronous. There is no way of making it synchronous in Meteor. However if you are ok with synchronous simulation result then you can use that.
@zimt28 yes it's shouldn't be hard to implement. I have a nice idea for API that would make relations definition very easy.

Will Astronomy work in environments like React-Native?

@smooJitter haven't tested it but it should work without the problem

Hello, What version of Meteor does the latest 2.0.0 rc6 draw on?

@smooJitter it uses Meteor 1.3 beta. I'm trying to make it work with 1.2 too.

When using  rc5 build and Meteor's 1.3 beta 12, I receive the following.
While processing files with ecmascript (for target web.browser):
packages/jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super() outside of class constructor
(10:4)
packages/jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super() outside of class constructor
(10:4)
packages/jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside of class constructor
(12:2)
While processing files with ecmascript (for target os.windows.x86_32):
packages/jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super() outside of class constructor
(10:4)
packages/jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super() outside of class constructor
(10:4)
packages/jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside of class constructor
(12:2)

@jagi Happy to help :) Would love to see what you came up with!

@smooJitter it was already fixed in a version that is on GitHub but haven't been published to Atmosphere as it's not possible right now to publish packages for Meteor 1.3 beta.

Sorry for the all bold text.  I actually installed the package by updating simply adding and entry to the  package.json file and letting the rebuild pick it up

since relations won't be included in 2.0 does that mean that will continue to use the relations package that currently exists or that 2.0 will be without relations for a little bit? Just curious as I have begun working on a package and deciding between 1.x and 2.0

I am wondering about relations myself as well.
With 1.x I could do this:
...
        emails: {
            type: 'array',
            nested: 'Email',
            default: function() {
                return [];
            }
        },
        relations: {
            sites: {
                type: 'many',
                class: 'Site',
                local: '_id',
                foreign: 'cardId'
            }
        }
       ...

If I wanted to have relations like this in 2.0 how would I go about it, I am starting a new project as well and would love to use 2.0 but I do need one-to-many "foreign key" style features.
If the "relations" features aren't implemented in 2.0 what do you suggest if we want to start using 2.0 but want to use relations type features.
Thanks in advance :)

@mgarf @JasonWeise relations won't be available in 2.0 but in 2.1 so it's just the next feature that I'm gonna implement after releasing 2.0.
Current relations package won't work with 2.0.
It's not so hard to implement relation methods by hand.
Card = Astro.Class.create({
  name: 'Card',
  collection: Cards,
  fields: {
    ...
  },
  methods: {
    sites: function() {
      var cursor = Site.find({
        cardId: this._id
      });
      return cursor;
      // or
      return cursor.fetch();
    }
  }
});

In 2.1 I was just planning to support something like this:
Card = Astro.Class.create({
  name: 'Card',
  collection: Cards,
  fields: {
    sites: {
      type: [Site],
      foreignKey: 'cardId'
    }
  }
});

var card = Card.findOne();
card.populate('sites');
card.sites[0];

However after proposition of @zimt28 I'm planning to introduce syntax that would support both implementations but don't have idea how to structure API, maybe something like this:
Card = Astro.Class.create({
  name: 'Card',
  collection: Cards,
  fields: {
    sites: {
      type: [Site],
      foreignKey: 'cardId',
      accessor: 'getSites'
    }
  }
});
var card = Card.findOne();

card.populate('sites');
// or
card.getSites().find();
card.getSites().insert();
// etc.

But I would like to hear your opinion and maybe get some ideas.

@jagi Why not just use the field key, so it would be card.sites().find() or even card.sites.find() if Astronomy can handle this internally? Like "oh, this got a foreignKey, so it has to be a relation. I better replace this object with another one, which gives the user some methods to work with" :smile:

Perhaps this can be inspiring
https://laravel.com/docs/5.1/eloquent-relationships

So if someone is interested in relations, please give some feedback:
(just note that as I don't know how it could look like in Astronomy, the example uses collection-helpers)
https://gist.github.com/zimt28/9cfc0f76118a77d37d2a#file-relations-hasmany-js-L4-L35

Haha yeah, what I tried there is quite "inspired" by Laravel :smile:

@jagi Thanks so much for the tips on relations, this has now convinced me to go with v2 for the start of our project. I have just tried to use astronomy v2.rc5 on Meteor 1.3-beta.11 and receive the same error as @smooJitter
While processing files with ecmascript (for target web.browser):
   packages/jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super() outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super() outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside of class constructor (12:2)

   While processing files with ecmascript (for target os.windows.x86_32):
   packages/jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super() outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super() outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside of class constructor (12:2)

You mentioned you can't publish packages for Meteor 1.3 beta, is there a way I can use the version of Astronomy with the mentioned fixes.
I installed Astronomy 2.0rc5 with the following and all installed ok..
> meteor add<EMAIL_ADDRESS>>meteor add<EMAIL_ADDRESS>
I guess I just need to figure out how to "merge" your latest changes so I can get past these errors.

I had the same problem

@smooJitter, did you manage to fix this problem. Seems we have the same issues.

@jagi alright our team is about to start migrating to Astronomy 2.0 :). Quick question, how do custom validations work with 2.0? For example:
Astro.createValidator({
  name: 'uniqueEndpointResponseCodes',
  validate() {
    // logic here...
    return true;
  },
  events: {
    validationError(e) {
      e.setMessage(`Each response code may only be used in one response definition.`);
    },
  },
});

Oh a lot of comments from my last visit here :). Ok so let me split this discussion into separate threads, right now we are talking here about everything :). @zimt28 I will start soon a new discussion only about relations in Astronomy 2.1. I know that there are several possibilities and I will take all of them into account when designing API. So let just postpone this discussion a little bit ;)
If it goes about new version of Astronomy (rc.6) which is on GitHub but haven't been published. You can just clone this repository into your packages directory and work with it locally. Let me know if it works for you.
@marbemac If it goes about creating custom validator, for now, the best place to look how to do it is a source code of validators module: https://github.com/jagi/meteor-astronomy/blob/v2/lib/modules/validators/validators/size/length.js Of course you don't have to use ES modules. And you can replace Validator.create with Astro.Validator.create when not using ES modules.

@jagi thank you very much for the reply.
My specific issue was with the rc.6 version of Astronomy. I have had a look and you have suggested to clone the repository into the packages director, I don't seem to have a packages directory on Meteor 1.3-beta.11 .
Sorry if it is a daft question, but I have installed rc.5 with meteor add .... , but as explained, I cannot see a packages directory in my project - I am using the Mantra framework and Astronomy 1.2 worked fine with a previous project.
Thanks so much in advance

So I would suggest using environment variable for packages PACKAGE_DIRS=your_packages_directory && meteor
your_packages_directory - should be a directory where you will store astronomy package folder

@jagi thank you soooo much, I have been ripping my hair out for the last 60 minutes. I didn't even realise that PACKAGE_DIRS existed.
Thanks heaps....

@JasonWeise no problem :)

Small feature request for 2.0: It would be nice if we could set a schema property instead of fields, same thing - different name. I want to pull out the field definitions to keep the model more readable, and I think having a schemas folder is clearer than having a fields folder.

@zimt28 I don't think that changing property name is a good idea. And having two possibilities is even worse. I don't see any benefit of changing that name. And I don't understand what correlation it has with the folder name.

Will version 2.0 also be compatible with Meteor 1.2?

@Ben305 I'm working on making it compatible with 1.2. It's not so easy as it uses ES modules.

Sounds good, there's a package to use ES modules in meteor 1.2: https://github.com/vazco/universe-modules
Let me know when you're done, so that I can test and give you feedback :+1:

@jagi Makes sense, I've just created Model and Schema functions to have an API I like :)
One more thing: Is the name property required? Is it possible to just omit it?

@jagi any update on getting the latest changes working on Meteor 1.2? I feel this is a problem that alot of package maintainers would have, isn't there a good approach to handle this? If not, maybe discussing this on Meteor forums is a good idea?

@zimt28 the name is required, it's used internally in many situations.
@talha-asad I've asked about this problem but they said it's not possible to run packages with ES modules in Meteor 1.2. However, I will try to make a workaround that will allow this. But right now I'm more focused on making all the fixes and later I will make it work with Meteor 1.2

@jagi is there a way to skip validation on save? Something like foo.save({validate: false})?

@marbemac I asked the same question above at here and @jagi responded at here.Basically he suggested using direct Mongo Collection operations in this case.

Do we have to set the entire user object each time? We don't have specific fields that we're saving - like:
var rawValues = user.raw();
Users.upsert(user._id, { $set: rawValues });

I don't know what @jagi think of on this one, but IMO it depends on really how change you want to have. If all you want to do is to alter one field, then just set the value for that field (and of course you need to check for data integrity manually in this case).

@marbemac @minfawang in the version that is on GitHub there is a way of not validating a document on the client.
var doc = Docs.findOne();
doc.name = 'New Name';
doc.save({ environment: 'server' }, function(err) {
});

Of course that way it will only be validating and inserting on the server even though a call was made on the client. Additionally you can do something like this:
var doc = Docs.findOne();
doc.name = 'New Name';
doc.validate({ fields: ['name'] }, function(err) {
  if (!err) {
    doc.save({ environment: 'server' }, function(err) {
    });
  }
});

@jagi That's more neat than writing direct collection operations! :+1:

@jagi does rc5 include the fix for Loose mode ? I'm still getting the error that was mentioned above using Meteor 1.3-beta.12 (Mantra) and the<EMAIL_ADDRESS>package.
   While processing files with ecmascript (for target web.browser):
   packages/jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super()
   outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super()
   outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside
   of class constructor (12:2)

   While processing files with ecmascript (for target os.osx.x86_64):
   packages/jagi:astronomy/lib/modules/fields/fields/scalar_field.js:10:4: super()
   outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/object_field.js:10:4: super()
   outside of class constructor (10:4)
   packages/jagi:astronomy/lib/modules/fields/fields/list_field.js:12:2: super() outside
   of class constructor (12:2)

@ianserlin Would be awesome if this worked, but throwing an error in the before save/insert/etc doesn't seem to stop this from running on the server, so I'm not sure what the below accomplishes? If meteor methods are being used internally, then this makes sense because throwing an error in the client simulation does not prevent the method from completing / running on the server.
Astro.Class.create({
     name: 'Car'
 ...
, events: {
     beforeInsert: [
         function checkUserID (e) {
              var car = e.currentTarget;
              if(!e.trusted){
                    // run security checks
                    if( /* check doesn't pass */ ){
                          throw new Meteor.Error("not-allowed", "You don't have sufficient permissions to create a car.");
                    }
              }
              // request to insert came from server-code, explicitly trust
         }
         , function checkSomethingICareAbout (e) {
            // ... some other kind of check, possibly using `e.trusted` to determine if we need to run the check
         }
     ]
 }
});

We are trying to migrate from Astronomy 1, and the change to use methods internally is making things pretty difficult. Basically, we need users to not be able to save on the client (as we have methods that do this ourselves), and Astronomy 1 worked this way by default because the default is to deny.

@purplecones rc5 does not solve this problem. However, version that resides on GitHub does. I will try to publish this version before Friday.

@marbemac It's how Meteor works. Throwing an error in the simulation does not prevent server method to be called. As the name says it's only simulation of what will be happening on the server. You can change this method to be only server side.

In the newest commit I've added enums. Example:
import { Class, Enum } from 'meteor/jagi:astronomy';

Status = Enum.create({
  name: 'Status',
  options: {
    OPENED: 0,
    CLOSED: 1,
    DONE: 2,
    CANCELED: 3
  }
});

Issue = Class.create({
  /* ... */
  fields: {
    status: {
      type: Status,
      default: Status.OPENED
    }
  }
});

This will automatically attach proper validators to the field. New version works with Meteor 1.3-beta.16. I will try to publish it to the Atmosphere.

:+1: Thanks jagi, have been waiting for that one. Were you able to make any progress on getting the latest rc working with Meteor 1.2.1 or should i be upgrading to the latest Meteor as well?

@marbemac The server method might be run, but if you're throwing an error the save shouldn't hit the database.

@talha-asad I will be working on publishing Astronomy 2.0-rc.6 to Atmosphere and trying to make it work with Meteor 1.2.x. The enum type was the last feature to implement before releasing 2.0. Relations will appear in 2.1. So right now I will focus on fixing any bugs, making more detailed tests and documentation.

You are only throwing an error in the block of code run on the client, which does not stop it from also running on the server. In your example, anybody can call save on that model in their web browser console, and while it will throw an error in the browser console, it will get persisted to the db on the server.
@jagi, this is how meteor methods work, and perhaps this design is inspired by how meteor collections work w methods under the hood, however, meteor collections respect allow deny rules. We don't even use allow deny rules, but the default is to deny, which is crucial and prevents users from being able to insert records from the web browser.
So my question is - how can we prevent users from being able to insert from the web browser, which is a huge security hole? Simply throwing errors / rejecting in event hooks when on the client is inadequate, since it will still run on the server.

@marbemac

You are only throwing an error in the block of code run on the client...

That is only true if you are only defining the beforeInsert on the client.
The one other case you could be running into is if you are defining your own meteor method that is calling .save on a model. In that case the e.trusted property will be false when it runs on the server because it is the server instance of your custom meteor method that is running and calling .save. The upshot is that if you define your own meteor methods to do database operations you are responsible for writing your own custom auth.
Unless I'm completely missing something about your question. If you post some example code I can try to help.

Oh, is that what e.trusted is? I completely missed that, I thought it was false when running on the client, and true when running on the server, no matter the "callee" of the .save(). Ie if you call save from a server side method, e.trusted will be true. If this is the case, where e.trusted is false even when running from my own custom server methods, when will e.trusted ever be true?
In any case, I don't see a way to prevent users from saving/removing etc from the client. I cannot do a Posts.insert({}) from my browser (via meteor collection), but I can do post.save() from my browser (astronomy model instance). It might throw an error in the browser because I deny clientside, but ultimately it is persisted to the server, because of the way astronomy 2 uses methods which don't allow you to stop the server action from happening from the client simulation.

Phew, ok I think we've got it. It's a bit of a different way to think about securing this stuff, we've totally ditched our custom create/update/delete methods. Jagi the little trick you're using for optional works very well for immutable as well :), ie:
owner: {
  type: String,
  immutable: !Meteor.isServer
}

This is a great way to prevent users from updating certain fields, but still allow us to update it from trusted server stuff.

@marbemac Good to know, I'm working on that part of the documentation. e.trusted will be true if and only if the call to .save was initiated by client-side code directly (e.g. not via a custom meteor method defined by your app).

@ianserlin you wanted to write "e.trusted will be true if and only if the call to .save() was initiated by SERVER-side code directly" :)
@marbemac Ian is originator of the e.trusted property which was crucial for security in the Hail messaging platform and he will describe that part in the documentation. I'm always open to any suggestions, especially if it goes about security. Right now it's a good time to check if there are any security holes. I will be making my own tests to make sure that everything plays nicely. In Astronomy 2.0 there are some changes in how it handles security but documentation will explain everything.

UPDATE
I've published<EMAIL_ADDRESS>and<EMAIL_ADDRESS>However they will only work when used with Meteor 1.3-beta.16
I will be working now on making it work with Meteor 1.2

Nice! And I'll try if it works with Meteor 1.3-rc.2 as well.

UPDATE
I've published<EMAIL_ADDRESS>and<EMAIL_ADDRESS>because I've introduced a little bug in the previous version. Now it should work with Meteor 1.3-rc.2 which I didn't noticed when publishing the last version.

I'd really love to see it work on Meteor 1.2, sadly our projects are still on stable branch :(

Meteor 1.3 release is planned for the end of March. I hope that many people will switch to 1.3. However, I'm planning to use universe:modules for backward compatibility with 1.2. I will be talking with package authors in 2 weeks. I won't be available for next 2 weeks. So you all have to wait :)

@jagi Source for release time of Meteor 1.3? I'm excited!

I've tried to find a thread when Ben Newman was posting release date but don't know where it was. He said it will be 24th or 25th.

@jagi It is March 21st
https://forums.meteor.com/t/what-is-the-meteor-1-3-release-date/19709

Oh sweet baby jesus.

is this v2 needs meteor as dependency..?? i'm going to play around with react native and graphql... i don't see i need meteor for this...
will you going this v2 as npm..?? react native runs within node.js runtime so most of pure javascript modules for node should work with react native...
i'm taking course for react native and graphql but still don't get how to integrate both of two.. as i understand how astronomy work,, i hope astronomy will give me some light for this...
what i see from the course,, react native work with firebase... but i need solution for self hosted sql based db... i see graphql should be a solution for this...

It sounds like v2 is pretty tied to Meteor, but it would be amazing if this could somehow work without meteor, as a standalone npm package. We're about to build an API outside of meteor, and being able to make use of these models would greatly increase the shared code amongst our products. Not to mention, the broader NPM community would likely be interested in what you've put together here!

woow that's great... i'm watching that..!!
yes agree.. npm is a future... even meteor starting to move to npm...

@MeKarina @marbemac v2 is tightly integrated with Meteor. However, my plans for future releases are to make it an NPM package and create Meteor package that adds some extra Meteor specific feature. However, first I have to play around with React in Meteor and I'm still waiting for Apollo for GraphQL support. So it's hard to tell how it will look like.
As I'm now back from vacations I will try to release Astronomy 2.0 as fast as possible. However, I have a few challenges with security.

I'm not sure if this package helps
https://github.com/agutoli/react-entity

It will work a similar way, however there will be much more features :)

I defined a field as type Number and I'm trying to add a decimal value such as 0.02 into it but get the following error:
Error: "current_return" has to be a number [validation-error]

Is there a list of all field types listed somewhere? I did not see float or decimal in v1.

@purplecones You probably assigned string from the field instead number. Strings are not converted to numbers automatically. Please not write about issues like that in this thread. It's only dedicated to features that will appear in the 2.0

When I try to test the RC, I get this error:
Conflict: Constraint<EMAIL_ADDRESS>is not satisfied by jagi:astronomy 2.0.0-rc.7.
Constraints on package "jagi:astronomy":
*<EMAIL_ADDRESS><- top level
*<EMAIL_ADDRESS><- jagi:astronomy-relations 1.0.0
*<EMAIL_ADDRESS><- jagi:astronomy-slug-behavior 1.3.0
*<EMAIL_ADDRESS><- jagi:astronomy-validators 1.1.2

When I try to add<EMAIL_ADDRESS>I get this error:
error: Conflict: Constraint<EMAIL_ADDRESS>is not satisfied by jagi:astronomy 1.2.10.
Constraints on package "jagi:astronomy":
*<EMAIL_ADDRESS><- jagi:astronomy-relations 1.0.0
*<EMAIL_ADDRESS><- jagi:astronomy-slug-behavior 1.3.0
*<EMAIL_ADDRESS><- jagi:astronomy-validators 1.1.2
*<EMAIL_ADDRESS><- jagi:astronomy-timestamp-behavior 2.0.0-rc.4

Hi i wanted to add something peculiar to the discussion.
The closure of Class methods on the client is the window object => _this:window
The Model is in a top lib folder and accessed by both.
Im not sure if im doing something wrong so im posting this here before creating an issue..
Thanks

@tylershuster I would recommend you remove all previous versions and then start adding new ones, they will most probably get you across the version incompatibilities you are facing.

@leosa83 you are probably doing something wrong because it's default behavior that method's context is a document.

@talha-asad Right on. Had to manually delete the packages from .meteor/packages if anyone else has the same problem.

I've published the following packages versions:

<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>All are compatible with Meteor 1.3
In the core package here is a list of changes:
The "disableEvents" option in the find method
The getModifier method
Fix error with inserting undefined values
Fix error with not validating lists of documents
Other small fixes

@jagi Can you leave specific instruction on how to integrate/create a simple model for a User (id, name, email - nothing more) so we can try out rc.8?
What is softremove-behavior? Is it needed for Astronomy? Thanks! Excited to integrate it here https://github.com/danieltapia/tiki

Is rc8 compatible with 1.2.1 as well?

@sergiotapia here you have the sample application up to date with the current version of Astronomy https://github.com/jagi/meteor-astronomy-examples/tree/v2
@talha-asad it's not compatible with 1.2.1. I don't know if I'm gonna have time to make it compatible. I have to work on documentation right now.

push, inc, pop methods have been removed .

I'm wondering how to manage very big arrays with Astronomy. In my Mongo requests I use the fields attribute to avoid loading big arrays. But I would like to simply add an element at the end of big arrays, or to remove an element, without having to load these big arrays in memory. Is it possible with Astronomy 2 ?

@laurentpayot I believe you can use the same type of mongo modifier and just pass it to the <Class>.update method instead of the <Collection>.update method that you normally would. E.g. if you had a collection called Products and a model called Product you could do Product.update({ ... }, { $pull: { ... } }) to use that syntax but still get all the Astronomy goodness you have wired up.

@jagi I think it's pretty straight forward from what I see at the migration guide for 1.3, however actual mileage may vary, here is my understanding. You need to export using api.export as was the norm in  < 1.3. And use api.mainModule() and export from your main module as well.
I am going to pull your latest code and give it a try.

@ianserlin A long time ago I realized that in Astronomy (v1) you could not use push() along with set() so I used direct Mongo collection pushes within Astronomy methods but as far as I remember I had weird results after save().
I will try again with Astronomy v2 but having to bypass Astronomy for a simple push looks like a bug to me. What do you think @jagi ?

@laurentpayot in most cases you will have to load entire document (at least on the server) to perform such operation with Astronomy. That's how Model layer works. It's not perfect but it helps in many situations. The problem with not loading entire document is that you can't check integrity without doing so. Let's say you have to check number of elements in the array. How are you gonna do that without loading entire document? So in such cases you have to use standard Collection methods.
@talha-asad if you want to work on this, that would be great. Any help will be appreciated.

@jagi For push/pull/etc is it possible to use the Class mutation methods (ModelClass.update/etc) and then call reload() on your model instance if you need to do subsequent saves with it?

@jagi Thanks for your answer, it makes sense. Will try some workarounds.

@sergiotapia I forgot to answer your question about the softremove behavior. You don't have to use it as long as you don't need softremove behavior :). It just removes a document without removing it from the collection. It marks it as removed and later such documents won't be fetched from collection until you restore it. This behavior introduces 4 methods:
doc.softRemove(optionalCallback);
doc.softRestore(optionalCallback);
Class.softRemove(optionalCallback);
Class.softRestore(optionalCallback);

It behaves similarly to the doc.remove() and Class.remove() methods.
@laurentpayot no problem.
@ianserlin in theory yes. If you modify some document using Class.update() then all the subscriptions will reload and because of that you can also reload your document doc.reload() that was modified with the Class.update()`. However, timing is a problem. In all tests I was making, in the callback function you can reload a document without the problem. So it's probably called after subscriptions are reloaded. But I don't know if you can depend on it in 100%.
doc.name = 'New name';
doc.save(() => {
  doc.reload(); // It works
});

Class.update(doc._id, {$set: {name: 'Another name'}}, () => {
  doc.reload(); // Should also work
});

Thanks @jagi, I'm going to look into those examples.

I have a class User attached to the Meteor.users collection. When I run User.find().fetch() on client or server, there are no results. When I run User.getCollection().direct.find().fetch() to see if the class is attached to the right connection, the users show up.

@tylershuster please create separate issue for such problems. It's hard to tell what's wrong without seeing the code.

@jagi Please fix the version in the first post<EMAIL_ADDRESS>-><EMAIL_ADDRESS>

@talha-asad thanks for noticing this, fixed

And as Astronomy is modularised, then it will be very easy to develop some package/module called for example jagi:astronomy-react :)
IMHO jsx files syntax is the worst thing that happened to computer science since PHP, so I'm using the amazing Vue as my view layer. As Astronomy is supposed to be view-layer agnostic, will it be possible to integrate v2 with any view-layer system ?

@laurentpayot it should be possible. I'm not familiar with Vue view layer but after looking at the example I think it shouldn't be a problem to use Astronomy with it.

Documentation for v1 is temporarily located under this address http://jagi.github.io/meteor-astronomy/v1 - it's not "recovered" entirely yet. Probably, it will be available tomorrow. I'm also working on docs for v2. Right now I try to focus on the content of the documentation. So any UX/UI improvements will be added after it's ready.

@jagi How would I use ENUM to get a list of options? eg.  for a select box to have OPENED,
CLOSED,
DONE,
CANCELED,

@chathuraa you have an example of ENUM usage in this thread https://github.com/jagi/meteor-astronomy/issues/236#issuecomment-196754072

Hi @jagi, when do you think v2 will be ready? An is there an event which covers all beforeInsert/Update/Remove?

It's actually ready but I won't release it before finishing documentation. It should be ready before the end of April

No there is no such event. What do you need it for?

When checking permissions it's basically the same function for all of them, the only difference is the mode. So it would be cool to have a before or beforeAny method or something similar which provides the current mode (insert, update, remove) via e.mode or so.

If think it's very rare use case so I'm not going to introduce one but you can do very easy trick:
function generateEvent(mode, eventHandler) {
  return function(event) {
    if (mode === 'insert') {
    }
  };
}

// ...

events: {
  beforeInsert: generateEvent('insert'),
  beforeUpdate: generateEvent('update'),
  beforeRemove: generateEvent('remove'),
}

Or something similar

Yeah, that's what I'm currently doing. Maybe I could write a behavior instead? Haven't looked into those yet.

This would commonly be done in a beforeValidate hook - this is where you can put your custom common validations (or acl checks). See mongoose for an example:
http://mongoosejs.com/docs/api.html#document_Document-validate

@marbemac The only problem is that I do not validate documents on removal. There is no point of doing so.
@zimt28 It might be probably done as a behavior.
Any way I'm not going to introduce new features until release of 2.0.

Ah, true, that makes sense.

Thanks. Small feature request: The argument passed to the events should include the class name - access checks would be even simpler then :) Let us know if you need someone to have a look at the new docs if that would help you!


weird result of sar sim

It's result of bitfinex.ETC-BTC  simulation by sar.
when sell, rate to sell is higher than current rate.
Even though next period rate is down, printed bought.


Update Helm release nfs-subdir-external-provisioner to v4.0.18

This PR contains the following updates:

Package
Update
Change

nfs-subdir-external-provisioner
patch
4.0.17 -> 4.0.18

Release Notes

kubernetes-sigs/nfs-subdir-external-provisioner (nfs-subdir-external-provisioner)
v4.0.18
Compare Source
nfs-subdir-external-provisioner is an automatic provisioner that used your already configured NFS server, automatically creating Persistent Volumes.

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

Renovate Ignore Notification
Because you closed this PR without merging, Renovate will ignore this update (4.0.18). You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


Swish

This PR adds new activation function: Swish

so en vogue!

After reading 28 tweets about swish today - i gave up and opened laptop.
ср, 18 окт. 2017 г. в 18:26, Max Pumperla<EMAIL_ADDRESS>
so en vogue!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/deeplearning4j/libnd4j/pull/519#issuecomment-337629405,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALru_xvNiBcxOztUT8verm1sM_mDerCQks5sthisgaJpZM4P94iV
.


Push access for new maintainers?

@swang @clutchski There are a lot of open issues and PRs left ignored; I for one would like to be given push/release access to address some of these… I also have a number of PRs to the @aminland /coffeelint2 fork of this project. With eslint-plugin-coffee we can have nice modern linting for CoffeeScript.

@danielbayley I have forked it to coffeelint/coffeelint and will release new versions as @coffeelint/cli as per @clutchski's request.
If you still want to help maintain it I could add you as a maintainer.


[SPARK-46501][INFRA] List the python packages with the correct versions

What changes were proposed in this pull request?
List the python packages with the correct versions
Why are the changes needed?
the version here should be in PYTHON_TO_TEST
Does this PR introduce any user-facing change?
no, infra-only
How was this patch tested?
ci
Was this patch authored or co-authored using generative AI tooling?
no

test python3.9,python3.11,python3.12
https://github.com/zhengruifeng/spark/actions/runs/7320212846/job/19939564692

thanks @dongjoon-hyun


jest 28/29 support

when is the release with jest 29 support planned 0 its already in master ?

it's merged 3 months ago ...

There's still this (rather large) issue: https://github.com/preactjs/jest-preset-preact/pull/13#issuecomment-1403785276
I'd suggest to keep using older versions of Jest if possible.

The installation of the jest-preset-preact complains about jest dependency aboce @27. Is there any workaround for that?

Besides adhering to the peerDependency range and using v27? Not really.

Thanks a lot

I can push a release tonight maybe, though the linked issue is still a very real problem that we haven't found an answer for.

Released v4.1.0
Let me know if there are any issues.


fix dma_buf_export for kernel version 3.10.0

Checking if libgmp.so.3 before cloning libgmp.so.10 in Makefile.
The current kernel version of Centos 7 is 3.10.0 in which dma_buf_export only takes a single argument.

Installing Bluespec on Centos 7 requires the following packages:
sudo yum install gmp glibc-devel autoconf gperf compat-libstdc++-33
yum couldn't find iverilog package, so we have to build iverilog from source:
git clone https://github.com/steveicarus/iverilog.git
cd iverilog
sh autoconf.sh
./configure
make
sudo make install

Link libgmp.so.3 if needed:
sudo ln -s /usr/lib64/libgmp.so.10 /usr/lib64/libgmp.so.3

@jameyhicks I've added more branches for choosing the right version of dma_buf_export according to the host kernel version.


IE 11 error when use *ngFor for array of objects

I'm submitting a ...
[ x] bug report
[ ] feature request
[ ] question about the decisions made in the repository

What is the current behavior?
Error in IE11 when I try to use *ngFor for array of objects

Please tell us about your environment:

Angular version: 2.4.3
Browser: [IE11 ]

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
http://stackoverflow.com/questions/43206736/angular2-ngfor-array-of-objects-ie11-error

I had to add core-js to index.html to repair that, I don't know why, considering that it should be loaded by webpack (it's in polyffils.browser.ts)

it looks like the issue was solved by the comment above
Thank you for the issue. Please follow issue https://github.com/AngularClass/angular2-webpack-starter/issues/1686 for updates into Angular version 4+


add prediction_gradient method for MLPs

This adds a method to facilitate the interpretation of MLP model predictions.  Specifically, it enables one to compute the gradient of the final output layer (pre-sigmoid logits for logistic regression, etc.) with respect to the input features.
I'm leaving sparse inputs to a future PR.  Also, I have some notebooks illustrating the method on toy datasets that might be worth adding.

@hinnefe2, any interest in reviewing this?

Sure thing

What do you think of a warning if this is called on data with large variation in feature ranges...

I'd prefer not to add a warning since it might be hard to get that right, and it might be annoying.  Also, I wouldn't want somebody to think the lack of a warning means that things are perfect.  How about a comment to the docstring?

Let's not coddle our users. They have to know what they are doing no matter how many warnings we throw at them. :)


Fix Player ID Parameter Parsing

This patch fixes the parsing and processing of media package IDs which
may not be loaded with the previous code, causing the player to
completely fail (it now fails all the time with the new configuration).
Your pull request should…

[ ] have a concise title
[ ] close an accompanying issue if one exists
[ ] be against the correct branch (features can only go into develop)
[ ] include migration scripts and documentation, if appropriate
[x] pass automated testing
[ ] have a clean commit history
[ ] have proper commit messages (title and body) for all commits
[ ] have appropriate tags applied

I will look into it :)


Rename to @storybook/builder-vite

What I did

[x] Rename storybook-builder-vite to @storybook/builder-vite
[x] Rename package folder

How to test

[ ] CI passes

Might be worth updating https://storybook.js.org/blog/storybook-for-vite/ as well?


Cronjob Support

Details
Helm chart name: chartlib

Describe the solution you'd like: Support for CronJob template

Anything else you would like to add: I think NetworkPolicy should be treated as a first class citizen not just a addons/vpn

Additional Information:

I am not convinced adding a CronJob controller to the common chart will be worth it IMO. CronJob specs are pretty different than Deployments, StatefulSets and DaemonSets and are generally pretty easy to write with little code. For example https://github.com/onedr0p/home-cluster/tree/main/cluster/apps/monitoring/uptimerobot-heartbeat
I don't have much to say about NetworkPolicy but maybe that is useful? I am not sure.

I am inclined to agree with @onedr0p on this. The idea behind the common chart is to be a library that is useful to a large part of our charts. I think only a very limited number of charts would benefit from having direct support for CronJob and/or NetworkPolicy objects.
NetworkPolicy objects are also very user-specific, so I would think the amount of yaml that would be written in the values.yaml file will end up pretty similar to just adding a NetworkPolicy manifest manually. But I must admit that I am not super well versed in them yet, so I may be completely wrong there 😛

I think it's a good idea to support CronJob and NetworkPolicy natively because it will only be a matter of time when someone would need it; that time is now and that someone is me 😅
I don't think it's an option for me to look for another chart library that has a NetworkPolicy implementation which I will then attempt to coexist with commons.
For NetworkPolicy we use it in all projects. I noticed there's an addons/vpn/_networkpolicy.tpl which I was hesitant to use hence I had to come up with the following. I followed the implementation of common.ingress
networkpolicy:
  aaa:
    enabled: true
    podSelector:
      matchExpressions:
      - {key: _some-key-here_, operator: In, values: ["_some-val-here_"] }
    egress:
    - ports:
      - port: _some-port-here_
        protocol: TCP
      to:
      - ipBlock:
          cidr: _some-cicdr-here_
  bbb: ...
  ccc: ...

I think it's a good idea to support CronJob and NetworkPolicy natively because it will only be a matter of time when someone would need it; that time is now and that someone is me 😅

Implementing something across almost all of our charts because a single user has a need is usually not the main reason why we do it 😉 Adding a feature means more maintenance, more chance of breakage and more mental overhead when trying to keep broad k8s version compatibility.

Also, I don't think it's an option to look for another chart library that has a NetworkPolicy implementation which will then be attempt to coexist with commons. I think doing so would be a horror to implement(?).

Depending on your exact use case it is not required to put all your manifests in a Helm chart. You can deploy the bulk of an application through Helm and add/store/apply the NetworkPolicy as a separate yaml manifest.

networkpolicy:
  aaa:
    enabled: true
    podSelector:
      matchExpressions:
      - {key: ..., operator: In, values: ["..."] }
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            name: ...
      ports:
      - port: ...
        protocol: TCP
    egress:
    - ports:
      - port: ...
        protocol: TCP
      to:
      - ipBlock:
          cidr: ...
  bbb: ...
  ccc: ...

This enforces my feeling that the content of values.yaml for networkPolicies would be pretty much the same as the actual manifest.

Implementing something across almost all of our charts because a single user has a need is usually not the main reason why we do it 😉 Adding a feature means more maintenance, more chance of breakage and more mental overhead when trying to keep broad k8s version compatibility.

I can't say for sure if i'm the only one who needs it. I did audited alternatives such as https://github.com/bitnami/charts/tree/master/bitnami/common/ and https://github.com/hmcts/chart-library. True enough though both of these doesn't supports NetworkPolicy as well. commons is my recommendation to my company thus all backend devs uses it and NetworkPolicy is always a requirement. CronJob is rare.

Depending on your exact use case it is not required to put all your manifests in a Helm chart. You can deploy the bulk of an application through Helm and add/store/apply the NetworkPolicy as a separate yaml manifest.

This also introduces another resource and possibly another library which is also a mental overhead for devs. The chart design I advocate to teams is to use a single application chart where participating microservices are just sub-charts and all the heavy lifting is provided by this sweet lib.

This enforces my feeling that the content of values.yaml for networkPolicies would be pretty much the same as the actual manifest.

I agree that it is indeed a passthrough just to complete a manifest but I think it does makes the implementation more cleaner and natural since it's just filling-in the blanks.
so yep, for us, we do need commons to support these 2 kube kinds and supporting these would be the right solution, where the rest would just be a workaround 😭
i give up  though 😭, please proceed to close this request enhancement.

I'm inclined to agree with @qgervacio there. I happen to have the same requirement to apply a common NetworkPolicy across dozens of clusters.
Now I'm not suggesting for a lib-chart that covers the whole k8s resource-types, but Jobs/CronJobs are getting pretty common, a lot of charts out there uses CronJobs as a pre-setup for their actual Deployment/DaemonSet
Plus, I think it's pretty normal for a library to expand its scope as time goes on.

I think the miscommunication here is rooted in the fact that the k8s-at-home library chart is intended as a library to be used for our own library of Helm charts.
It is very flattering and cool that it is being used outside of that realm, but (for now) its only intended goal is to make our own chart development easier.
I'll see if I can add a note to the README to communicate that more clearly, and I'll discuss with the fellow project maintainers if/how we want to expand the scope of the library.


Gap Analysis for GCP Object Lifecycle Management Support

Issue/Feature Description: Gap Analysis for GCP Object Lifecycle Management Support
Why this issue to fixed / feature is needed(give scenarios or use cases): To qualify the support metrics for SODA Multi-Cloud Lifecycle Management Feature for GCP backend
How to reproduce, in case of a bug:
Other Notes /  Environment Information: (Please give the env information, log link or any useful information for this issue)

Backlog of Iter1


Bring back Remove incorrect inheritance

Needs to be accepted with the same pr in services

https://github.com/opendatakit/services/pull/21

runtests

I think Mitch should review this so assigning


New robot.utils.is_noney utility function

This utility should return true if the value it gets is an actual Python None or a string containing None case-insensitively. In practice it ought to work similarly as the current is_truthy and is_falsy utils that are used by Robot itself as well as by various external libraries. Robot doesn't seem to have a need for is_noney at the moment, but at least Selenium2Library would need it.

After discussing with @aaltat about how his planning to handle string 'NONE' in Selenium2Library (see robotframework/Selenium2Library#843), it turned out that separate is_noney isn't really necessary. Better to change the current is_truthy/is_falsy to consider 'NONE' to be False.

is_noney removed and is_truthy('NONE') now returns false. This issue and #2656 are done.


[CMT-283] Announcements - Yearn & Synthetix DAO twitter space

https://github.com/yearn/yearn-comms/pull/637


Which ROMs are known to work?

Having trouble getting this to work, either permission issue, black screen, locks device, or reboots device.
Want it to work on Galaxy Note 1 (n7000), tried a couple of ROMs: Slimbean and ParanoidAndroid 4.2
Thanks

YMMV - it worked on the stock Nexus 7 4.2 ROM, I haven't tried it with any devices since then.

Thanks. I downgraded my N7 to 4.2 and it works. Great!


Forsyth county had two more-or-less identical fields appended to street name

The resulting addresses look like this:
-80.3742528,35.9841966,4830,BENT RIDGE LN LN,,,,,27012,,de141b70f9b55386
-80.0738147,36.0936321,1301,WHITWORTH CT CT,,,,,27284,,c9e1a10b3dda1327
-80.3550192,36.0937036,1116,ROCKDALE DR DR,,,,,27104,,1a55e71d6f47e88c
-80.1670648,36.0760055,3955,THORNABY CR CIR,,,,,27107,,439e67ab2452b9d6
-80.1988279,36.0380146,4006,HARTSOE RD RD,,,,,27107,,cf38f42a8c7447c1
-80.1888324,36.153153,4365,WAKEMAN DR DR,,,,,27105,,6061600bd7571223
-80.3289822,36.0643463,2851,HONDO DR DR,,,,,27103,,8a7590b163132ec1

Looks like STTYPE is a two-letter code for thoroughfare type and STTYPEPO is the USPS abbreviation. Using only the latter.

👍


missing hexadecimal prefix

I was experimenting with react-native-helios and encountered the following discrepancy when calling ethers.provider.getCode() against the Helios RPC:
const helios = getHeliosProvider(ethereumMainnet);
const alchemy = new ethers.providers.AlchemyProvider(
  'mainnet',
   apiKey,
);

const address = "0x00000000006c3852cbEf3e08E8dF289169EdE581";

const alchemyCode = await alchemy.getCode(address); // 0x60806040526004361015610013575b6...
const heliosCode = await helios.getCode(address); //<PHONE_NUMBER>6004361015610013575b6... (invalid hexlify value)

It looks like we're not returning with the expected hexadecimal prefix. If I add 0x to the response returned by Helios, the two responses are identical.
I'm running helios at 4c72344b55991b6296ccbb12b3c9e3ad634d593e; I'll bring this up to latest to see if the issue persists. 🙏

Apologies, realised this was fixed in #125. Stay awesome!


 TLS connections are also censored by IP addresses. Now it's hard to understand if a site just down or censored. So in the wake of http 451 code I propose to add a new ciphersuite,
CipherSuite TLS_CENSORED_WITH_CENSORED_CENSORED = { 0x01, 0xC3 }
(0x01c3 = 451)
to allow the censors (often censors are ISPs which emploees are also not happy with the situation) to show the people and the websites what the sites are not down/there are connections from that jurisdiction, but they are censored.

And see also HTTP error code 451.