fix: make the model key a tuple and simplified models code #28

bengineer42 · 2024-10-11T02:29:06Z

Make the model key a tuple and simplified models

glihm

Amazing work, crazy reduction of the generated code with that.

The new approach with the world looks great, as discussed with you and @remybar on discord it's a matter of making sure we support every use case since the compiler inference might be tricky.

Some general comments:

Add some documentation in the new modules and the need of each new traits.
Would be awesome to have in the examples/dojo_simple new cairo modules to showcase all the possible combinations (using the trait, using the world, etc..)
Adding some tests where we manipulate multiple models type in the same scope.

crates/compiler/src/plugin/attribute_macros/patches.rs

crates/compiler/src/plugin/attribute_macros/templates/model_store.generate.cairo

glihm · 2024-10-11T02:54:11Z

crates/contracts/src/model/attributes.cairo

+    MemberId: (felt252, felt252)
+}
+
+pub trait ModelAttributes<T> {


Not sure if Attribute is the word for that. We have a concept of definition recently added which regroup all those data, we may re-use this term here.

glihm · 2024-10-11T02:54:21Z

crates/contracts/src/model/entity.cairo

+
+pub trait EntityKey<E, K> {}
+
+// Needs to be generated


Suggested change

// Needs to be generated

crates/contracts/src/model/entity.cairo

crates/contracts/src/model/members.cairo

glihm · 2024-10-11T02:58:53Z

crates/contracts/src/tests/world/entities.cairo

@@ -456,7 +456,7 @@ fn test_delete_entity_by_id() {

    world.set_entity(selector, ModelIndex::Id(entity_id), values, layout);

-    world.delete_entity(selector, ModelIndex::Id(entity_id), layout);
+    IWorldDispatcherTrait::delete_entity(world, selector, ModelIndex::Id(entity_id), layout);


May be worthy to rename the delete_entity in the new implementation to avoid conflicts with the world trait.

glihm · 2024-10-11T03:01:25Z

crates/compiler/src/plugin/attribute_macros/model.rs

 use super::DOJO_MODEL_ATTR;

+const MODEL_CODE_STRING: &str = include_str!("./templates/model_store.generate.cairo");


Suggested change

const MODEL_CODE_STRING: &str = include_str!("./templates/model_store.generate.cairo");

const MODEL_CODE_PATCH: &str = include_str!("./templates/model_store.generate.cairo");

Let's call them patch or template.

glihm · 2024-10-11T03:03:55Z

crates/compiler/src/plugin/attribute_macros/model.rs

            .name(db)
            .as_syntax_node()
            .get_text(db)
            .trim()
            .to_string();
+        let model_name_snake = model_type.to_case(Case::Snake);


Suggested change

let model_name_snake = model_type.to_case(Case::Snake);

let model_type_snake = model_type.to_case(Case::Snake);

to be consistent with the change proposed here.

crates/compiler/src/plugin/attribute_macros/model.rs

Co-authored-by: glihm <[email protected]>

…ore.generate.cairo Co-authored-by: glihm <[email protected]>

remybar

Awesome work Ben ! 🚀 Thanks for this contribution !

I need to practice a little bit with this new way to manipulate models and entities to fully understand the impact, but it looks pretty great 👍

As @glihm said, we should play a little bit more with these new interfaces to be sure there won't be too many issues with compiler inferences even if there is always the possibility to explicitly specify the data types (but in this case, the DevX is degraded).

On another hand and on a general point of view, I'm wondering if we don't provide too many ways to set models/entities/members and if we should be more opinionated 🤔 Maybe we should select one way for each operation (probably the one which provides the best DevX) and document it well through examples and documentation. What do you think ?

remybar · 2024-10-12T06:05:28Z

crates/compiler/src/plugin/attribute_macros/model.rs

 use super::DOJO_MODEL_ATTR;

+const MODEL_CODE_PATCH: &str = include_str!("./templates/model_store.generate.cairo");
+const MODEL_FIELD_CODE_STRING: &str = include_str!("./templates/model_field_store.generate.cairo");


To be consistent, I would use _PATCH instead of _STRING.

Yeah missed that, will change

remybar · 2024-10-12T06:06:38Z

crates/compiler/src/plugin/attribute_macros/model.rs

@@ -56,16 +58,17 @@ impl DojoModel {
            &mut diagnostics,
        );

-        let model_name = struct_ast
+        let model_type = struct_ast


As in ModelDefinition we still use name() to get the model name, I would keep model_name instead of model_type here.

I think Type is more descriptive though as it is the type, even if we do use it in the contract

remybar · 2024-10-12T06:14:45Z

crates/compiler/src/plugin/attribute_macros/model.rs

@@ -176,6 +172,13 @@ impl DojoModel {
        );

        // Ensures models always derive Introspect if not already derived.
+        let derive_tags = derive_attr_names


Instead of derive_tags I would name this variable entity_derive_attr_names as it will be used to expand derive attributes of the underlying $model_type$Entity struct.

Okay will change

remybar · 2024-10-12T06:22:52Z

crates/compiler/src/plugin/attribute_macros/templates/model_store.generate.cairo

+    }
+}
+
+impl $model_type$EntityKey of dojo::model::entity::EntityKey<$model_type$Entity, $model_type$KeyType> {


I don't understand what is the goal of this empty trait (and the generic one EntityKey<E, K>) 🤔
Could you explain me please ?

Its to make sure that when you put the key in the get_entity function its the correct key type for the model Its a bit hacky, If you know a better way please let me know

Hum ok, thanks for the explanation 👍
I need to have a look but maybe using Associated types ?

remybar · 2024-10-12T06:24:55Z

crates/compiler/src/plugin/attribute_macros/templates/model_store.generate.cairo

+}
+
+// Impl to get the static definition of a model
+pub mod $model_type_snake$_definition {


I like the idea to split model traits in 2 parts: definition and entity. At the end, we can probably use the same Definition trait for both models and events.

remybar · 2024-10-12T06:48:50Z

crates/contracts/src/model/entity.cairo

+    fn delete_entity(self: IWorldDispatcher, entity: @E);
+    fn delete_from_id(self: IWorldDispatcher, entity_id: felt252);
+    fn get_member_from_id<T, +MemberStore<E, T>>(
+        self: @IWorldDispatcher, member_id: felt252, entity_id: felt252


I would put entity_id first and then member_id, to have a general-to-specific approach.
Same for update_member_from_id.

remybar · 2024-10-12T06:51:14Z

crates/contracts/src/model/entity.cairo

+    fn values(self: @E) -> Span<felt252>;
+    fn from_values(entity_id: felt252, ref values: Span<felt252>) -> Option<E>;
+
+    fn name() -> ByteArray;


Do we really need these definition functions here ? Would it be possible to directly use the ModelDefinition::xxx() or EntityDefinition::xxx() when needed ?

I did this to be more compatable with impls, I quite like them being part of model as it means useers only ned to use the Model Trait and the rest can be hidden but I'm not that attached to it

remybar · 2024-10-12T06:52:15Z

crates/contracts/src/model/members.cairo

+use core::panic_with_felt252;
+
+pub trait MemberStore<M, T> {
+    fn get_member(self: @IWorldDispatcher, member_id: felt252, entity_id: felt252,) -> T;


Same than before, I would put entity_id first and then member_id.
Same for update_member.

remybar · 2024-10-12T06:54:01Z

crates/contracts/src/model/members.cairo

+}
+
+
+fn update_serialized_member(


Here I would put parameters in this order: model_id, entity_id, member_id, layout and values, with the idea to first define the targeted member with a general-to-specific approach, and then provide the layout and values.
Same for other functions.

I think layout shoould be after model

remybar · 2024-10-12T07:02:13Z

examples/dojo_simple/src/lib.cairo

+
+        fn get_position(world: @IWorldDispatcher) -> Point {
+            let caller = starknet::get_caller_address();
+            let entity: PositionEntity = world.get_entity(caller);


If we can do this:

let mut position: Position = world.get(caller); position.x = new_x; position.y = new_y; world.set(@position);

I'm wondering if we still really need this concept of Entity 🤔

Have a look at this https://github.com/bengineer42/dojo-core/blob/value-store/0/crates/contracts/src/model/values.cairo#L22-L23

remybar · 2024-10-13T07:32:46Z

Hi @bengineer42 and @glihm !

I tried to list all the ways to get/set/update/delete models/entities/members. Have I forgotten any possibilites ?

I would say that we should remove get!, set! and delete! macros and give priority to world-centric functions like world.get() which are really clean from a DevX point of view (good job @bengineer42 👍).
I would also avoid ModelStore/EntityStore/MembersStore direct calls because the syntax is quite heavy.
I thought we could select to use models OR entities but both are really useful at the end, depending if the dev wants to use keys or entity ids.

#[derive(Drop, Serde)]
#[dojo::model]
pub struct Attack {
	#[key]
	pub player: ContractAddress,
	#[key]
	pub monster_id: u32,
	pub damage: u8,
	pub factor: u8,
}

use super::models::{Attack, AttackEntity, AttackMembersStore};

fn spawn(ref world: IWorldDispatcher) {
	let caller = starknet::get_caller_address();

	let entity_id = entity_id_from_key(@(caller, 12)); 

	//  ---- get  ----

	// ModelStore::get();
	let attack: Attack = world.get((caller, 12));

	// get! macro
	let _ = get!(world, (caller, 12), (Attack,));

	// EntityStore::get_entity()
	let attack_entity: AttackEntity = world.get_entity((caller, 12));

	// EntityStore::get_entity_from_id()
	let _: AttackEntity = world.get_entity_from_id(entity_id);

	// ---- get members ----

	// generated field accessors (MembersStore)
	let _attack_damage: u8 = world.get_damage((caller, 12));
	let _: u8 = world.get_damage_from_id(entity_id);

	// from ModelStore
	let _attack_damage3 = ModelStore::<Attack>::get_member::<u8, (ContractAddress, u32)>(
		@world, selector!("damage"), (caller, 12)
	);

	// from EntityStore
	let _attack_damage4 = EntityStore::<AttackEntity>::get_member_from_id::<u8>(
		@world, selector!("damage"), entity_id
	);

	//  ---- update  ----

	// ModelStore::set()
	world.set(@attack);

	// EntityStore::update()
	world.update(@attack_entity);

	// set! macro
	set!(world, (attack,));

	// --- update members ----

	// from MembersStore
	world.update_damage((caller, 12), 42_u8);
	world.update_damage_from_id(entity_id, 42_u8);

	// from ModelStore
	ModelStore::<Attack>::update_member::<u8, (ContractAddress, u32)>(
		world, selector!("damage"), (caller, 12), 42_u8
	);

	// from EntityStore
	EntityStore::<AttackEntity>::update_member_from_id::<u8>(
		world, selector!("damage"), entity_id, 42_u8
	);

	//  ---- delete  ----

	// from ModelStore
	world.delete(@attack);

	// from EntityStore
	world.delete_entity(@attack_entity);

	// from ModelStore
	ModelStore::<Attack>::delete_from_key(world, (caller, 12));

	// from EntityStore
	EntityStore::<AttackEntity>::delete_from_id(world, entity_id);
}

remybar · 2024-10-14T08:54:14Z

I noticed that the compiler is lost with the 2 delete_entity functions so we should rename one of them:

fn EntityStore::delete_entity(self: IWorldDispatcher, entity: @E);
fn IWorld::delete_entity(ref self: T, model_selector: felt252, index: ModelIndex, layout: Layout);

I played a little bit more with this world-centric solution and I think it should be fine for the type inference for ModelStore and EntityStore but for the MembersStore if 2 models have a same field (same name and same type) (which could be quite common in games), we will have to specify the type instead of calling get_<field_name> (and other field related functions).
A solution could be to use get_<model_name>_<field_name> but we will have long function names 😅

bengineer42 · 2024-10-14T09:11:23Z

I noticed that the compiler is lost with the 2 delete_entity functions so we should rename one of them

Yeah I saw this but I felt that both functions are used so rarely and also the fact that the IWorldDispactureTrait will not need to be imported as much now that I think it can be left (also I don't know what to rename it to)

bengineer42 · 2024-10-14T09:14:37Z

@remybar the get_<member_name> was also an issue with the previous versions, you can access it with MemberStore::get_<member_name>() if there are mutiple avliable implimenations but I'm also happy to change it to get_<model_name>_<field_name> (I actually had this format in a prevous commit a couple of months ago)

remybar · 2024-10-14T09:45:50Z

@remybar the get_<member_name> was also an issue with the previous versions, you can access it with MemberStore::get_<member_name>() if there are mutiple avliable implimenations but I'm also happy to change it to get_<model_name>_<field_name> (I actually had this format in a prevous commit a couple of months ago)

Yes, you're right ! Maybe something like AttackMembersStore::get_damage() is cleaner/easier to read than get_attack_damage(). So let's keep like that 👍

I think the most important point will be to well document in examples and the Dojo book how to do these things ^^

bengineer42 · 2024-10-15T09:41:50Z

crates/contracts/src/model/definition.cairo

+    MemberId: (felt252, felt252)
+}
+
+pub trait ModelDefinition<T> {


@glihm @remybar the newest update to main now has a Struct called ModelDefinition which will cause conflicts, What do you think the best way to resolve this is? Is the ModelDefinition struct even necessary/ever used?

Hi @bengineer42 !
It is the same trait than the one you added in your PR but coming from this merged PR (#10).
I think there is no conflict, it should be the same trait 🤔

Isnt the ModelDefinition in that PR a struct not a trait?

Isnt the ModelDefinition in that PR a struct not a trait?

Ah yes, understood 👍
Yes, this ModelDefinition struct is used to return the full model definition from the model contract, so you can get the whole definition with only one contract call instead of calling all the functions one by one.

Maybe we can juste rename the struct ModelDefinition to something else ?

Any suggestions? ModelAttributes, @glihm I know you didn't like this for the trait but I'm lost for ideas

Any suggestions? ModelAttributes, @glihm I know you didn't like this for the trait but I'm lost for ideas

ModelDef ? 😅
In fact, it provides the same information than the ModelDefinition trait ... So quite difficult to find a different name for that.

I think it is better to keep ModelDefinition for the trait as it will be used directly, while the struct name won't be used. We will do something like:

let definition = dispatcher.definition(); println!("{}", definition.name);

I will change ti to ModelDef for now just to keep it moving but if anyone has any better suggestions let me know

@remybar there are some inconsistencies between struct and trait, eg fn namespace_hash() -> felt252; vs pub namespace_selector: felt252,

pub trait ModelDefinition<T> { fn name() -> ByteArray; fn namespace() -> ByteArray; fn tag() -> ByteArray; fn version() -> u8; fn selector() -> felt252; fn name_hash() -> felt252; fn namespace_hash() -> felt252; fn layout() -> Layout; } #[derive(Drop, Serde, Debug, PartialEq)] pub struct ModelDef { pub name: ByteArray, pub namespace: ByteArray, pub namespace_selector: felt252, pub version: u8, pub layout: Layout, pub schema: Ty, pub packed_size: Option<u32>, pub unpacked_size: Option<u32> }

@remybar there are some inconsistencies between struct and trait, eg fn namespace_hash() -> felt252; vs pub namespace_selector: felt252,

pub trait ModelDefinition<T> { fn name() -> ByteArray; fn namespace() -> ByteArray; fn tag() -> ByteArray; fn version() -> u8; fn selector() -> felt252; fn name_hash() -> felt252; fn namespace_hash() -> felt252; fn layout() -> Layout; } #[derive(Drop, Serde, Debug, PartialEq)] pub struct ModelDef { pub name: ByteArray, pub namespace: ByteArray, pub namespace_selector: felt252, pub version: u8, pub layout: Layout, pub schema: Ty, pub packed_size: Option<u32>, pub unpacked_size: Option<u32> }

You can change to namespace_hash in the struct, thanks 👍 Maybe we should also add name_hash as it exists in the ModelDefinition trait.

remybar · 2024-10-16T09:20:47Z

Hi @bengineer42, @glihm !

From what Ben did on his branch, I tried to rearrange traits to have less traits to handle/generate. It's more an experiment than a fixed solution. The result is there: https://github.com/remybar/dojo-core/tree/make-key-tuple-bar1

The idea is to just use the following traits:

// use an Index to avoid having _from_key/_from_id functions
#[derive(Drop)]
pub enum Index<T> {
    Key: T,
    Id: felt252
}

// kind of merge of `ModelParser` and `EntityParser`.
// used to get index data from a model. 
pub trait IndexParser<M, K, +Serde<K>> {
    fn key(self: @M) -> K;

    fn entity_id(self: @M) -> felt252 {
        entity_id_from_key(@Self::key(self))
    }
}

pub fn to_entity_id<K, +Serde<K>>(self: @Index<K>) -> felt252 {
    match self {
        Index::Key(key) => dojo::utils::entity_id_from_key(key),
        Index::Id(id) => *id
    }
}

fn to_model_index<K, +Serde<K>>(self: @Index<K>) -> ModelIndex {
    match self {
        Index::Key(key) => ModelIndex::Keys(dojo::utils::serialize_inline(key)),
        Index::Id(id) => ModelIndex::Id(*id),
    }
}

// kind of merge of `ModelParser` and `EntityParser`.
// trait to implement for Model and ModelEntity
// `deserialize` replaces the `from_values` function.
pub trait DojoSerde<T, +Serde<T>> {    
    fn serialize_keys(self: @T) -> Span<felt252>;
    fn serialize_values(self: @T) -> Span<felt252>;

    fn deserialize(ref serialized_keys: Span<felt252>, ref serialized_values: Span<felt252>) -> Option<T> {
        let mut serialized: Array<felt252> = serialized_keys.into();
        serialized.append_span(serialized_values);
        let mut span = serialized.span();

        Serde::<T>::deserialize(ref span)
    }
}

// kind of merge of `ModelStore`, `EntityStore` and `MemberStore`.
// if we need model definition, we can directly use ModelDefinition<M> or eventually generates an impl `<ModelName>Definition` as it is done in the PR of Ben.
pub trait Model<M, K, E> {
    fn get(self: @IWorldDispatcher, key: K) -> M;
    fn get_entity(self: @IWorldDispatcher, index: Index<K>) -> E;

    fn set(self: IWorldDispatcher, model: @M);
    fn update(self: IWorldDispatcher, entity: @E);

    fn delete(self: IWorldDispatcher, model: @M);
    fn delete_entity(self: IWorldDispatcher, entity: @E);
    fn delete_from_index(self: IWorldDispatcher, index: Index<K>);

    fn update_serialized_member(
        world: IWorldDispatcher,
        entity_id: felt252,
        member_id: felt252,
        values: Span<felt252>,
    );

    fn get_serialized_member(
        world: IWorldDispatcher,
        entity_id: felt252,
        member_id: felt252,
    ) -> Span<felt252>;
}

Then, the generated code directly calls the Model and ModelDefinition trait without having some intermediate trait on the way.

At the end, we can use all this stuff like that:

#[derive(Drop, Serde)]
#[dojo::model]
pub struct Attack {
    #[key]
    pub player: ContractAddress,
    #[key]
    pub monster_id: u32,
    pub damage: u32,
    pub effect: u32,
}

let key = (caller, 12);

let attack = AttackModel::get(@world, key);
let attack_entity = AttackModel::get_entity(@world, Index::Id(42));
let _ = AttackModel::get_entity(@world, Index::Key(key));

AttackModel::set(world, @attack);
// I don't know why the compiler does not accept world.set(@attack); ...

AttackModel::update(world, @attack_entity);

AttackModel::delete(world, @attack);
AttackModel::delete_entity(world, @attack_entity);

AttackModel::delete_from_index(world, Index::Id(42));
AttackModel::delete_from_index(world, Index::Key(key));

let _ = AttackModel::get_damage(world, key);
let _ = AttackModel::get_damage_from_index(world, Index::id(42));
let _ = AttackModel::get_damage_from_index(world, Index::Key(key));

It would be nice to be able to do world.<FUNC_NAME>(...) but the compiler does not accept this kind of call and I don't know why because the impl Model is imported in the file ... 🤔

Don't hesitate to tell me what you think about that ;-)

bengineer42 · 2024-10-16T09:33:28Z

Hi @bengineer42, @glihm !

From what Ben did on his branch, I tried to rearrange traits to have less traits to handle/generate. It's more an experiment than a fixed solution. The result is there: https://github.com/remybar/dojo-core/tree/make-key-tuple-bar1

The idea is to just use the following traits:

// use an Index to avoid having _from_key/_from_id functions
#[derive(Drop)]
pub enum Index<T> {
    Key: T,
    Id: felt252
}

// kind of merge of `ModelParser` and `EntityParser`.
// used to get index data from a model. 
pub trait IndexParser<M, K, +Serde<K>> {
    fn key(self: @M) -> K;

    fn entity_id(self: @M) -> felt252 {
        entity_id_from_key(@Self::key(self))
    }
}

pub fn to_entity_id<K, +Serde<K>>(self: @Index<K>) -> felt252 {
    match self {
        Index::Key(key) => dojo::utils::entity_id_from_key(key),
        Index::Id(id) => *id
    }
}

fn to_model_index<K, +Serde<K>>(self: @Index<K>) -> ModelIndex {
    match self {
        Index::Key(key) => ModelIndex::Keys(dojo::utils::serialize_inline(key)),
        Index::Id(id) => ModelIndex::Id(*id),
    }
}

// kind of merge of `ModelParser` and `EntityParser`.
// trait to implement for Model and ModelEntity
// `deserialize` replaces the `from_values` function.
pub trait DojoSerde<T, +Serde<T>> {    
    fn serialize_keys(self: @T) -> Span<felt252>;
    fn serialize_values(self: @T) -> Span<felt252>;

    fn deserialize(ref serialized_keys: Span<felt252>, ref serialized_values: Span<felt252>) -> Option<T> {
        let mut serialized: Array<felt252> = serialized_keys.into();
        serialized.append_span(serialized_values);
        let mut span = serialized.span();

        Serde::<T>::deserialize(ref span)
    }
}

// kind of merge of `ModelStore`, `EntityStore` and `MemberStore`.
// if we need model definition, we can directly use ModelDefinition<M> or eventually generates an impl `<ModelName>Definition` as it is done in the PR of Ben.
pub trait Model<M, K, E> {
    fn get(self: @IWorldDispatcher, key: K) -> M;
    fn get_entity(self: @IWorldDispatcher, index: Index<K>) -> E;

    fn set(self: IWorldDispatcher, model: @M);
    fn update(self: IWorldDispatcher, entity: @E);

    fn delete(self: IWorldDispatcher, model: @M);
    fn delete_entity(self: IWorldDispatcher, entity: @E);
    fn delete_from_index(self: IWorldDispatcher, index: Index<K>);

    fn update_serialized_member(
        world: IWorldDispatcher,
        entity_id: felt252,
        member_id: felt252,
        values: Span<felt252>,
    );

    fn get_serialized_member(
        world: IWorldDispatcher,
        entity_id: felt252,
        member_id: felt252,
    ) -> Span<felt252>;
}

Then, the generated code directly calls the Model and ModelDefinition trait without having some intermediate trait on the way.

At the end, we can use all this stuff like that:

#[derive(Drop, Serde)]
#[dojo::model]
pub struct Attack {
    #[key]
    pub player: ContractAddress,
    #[key]
    pub monster_id: u32,
    pub damage: u32,
    pub effect: u32,
}

let key = (caller, 12);

let attack = AttackModel::get(@world, key);
let attack_entity = AttackModel::get_entity(@world, Index::Id(42));
let _ = AttackModel::get_entity(@world, Index::Key(key));

AttackModel::set(world, @attack);
// I don't know why the compiler does not accept world.set(@attack); ...

AttackModel::update(world, @attack_entity);

AttackModel::delete(world, @attack);
AttackModel::delete_entity(world, @attack_entity);

AttackModel::delete_from_index(world, Index::Id(42));
AttackModel::delete_from_index(world, Index::Key(key));

let _ = AttackModel::get_damage(world, key);
let _ = AttackModel::get_damage_from_index(world, Index::id(42));
let _ = AttackModel::get_damage_from_index(world, Index::Key(key));

It would be nice to be able to do world.<FUNC_NAME>(...) but the compiler does not accept this kind of call and I don't know why because the impl Model is imported in the file ... 🤔

Don't hesitate to tell me what you think about that ;-)

I think I might know why, but its a bit complex, are you free for a call to discuss? I have sent you an email but feel free to add me on discord!

glihm

Awesome work @bengineer42, let's iterate on that to push that further. 🔥

Thank you @remybar for the reviews and the time taken also on discussions for that.

bengineer42 added 30 commits October 4, 2024 19:34

Moved the code templates into files so they are nicer to work with

0513a32

Made the model attributes into a separate trait

7fa8954

implemented the attributes in the Model impl and contract

19bcb58

check this

0948491

check this

3f1b349

stash

e715a5b

stash

8a722aa

Stash

69f9678

Merge branch 'reduce-model-code/2a' into reduce-model-code/3

f5d28fe

stash

2e40797

stash

bb40f3f

stash

35085c5

fixing tests

fd0c0ec

fixing tests

0132dc5

stash

fcab67f

Merge branch 'main' into make-key-tuple/0

0952ea3

Sorry Glihm

54d7347

debugging

599a6bb

debugging

4181120

working, now moving to tests

f724768

Fixed members

f78f475

fixed

241c14e

fixed

fdf2aba

fixed worl.delete_entity

3e760e6

removed printing of models debug

b3dd5a0

removed printing of models debug

49e3306

Merge branch 'main' into make-key-tuple/2

b86d2b1

Merge branch 'main' into make-key-tuple/2

c985faf

formatting

565e828

fixing tests

5772c92

Fixed tests

e3c3870

glihm changed the title ~~Make the model key a tuple and simplified models~~ fix: make the model key a tuple and simplified models code Oct 11, 2024

glihm reviewed Oct 11, 2024

View reviewed changes

bengineer42 and others added 4 commits October 11, 2024 14:07

Update crates/compiler/src/plugin/attribute_macros/model.rs

434766a

Co-authored-by: glihm <[email protected]>

Update crates/compiler/src/plugin/attribute_macros/templates/model_st…

03bbb75

…ore.generate.cairo Co-authored-by: glihm <[email protected]>

Renamings

99d2d04

Addressing PR comments

3811770

bengineer42 requested a review from glihm October 11, 2024 13:48

Added more exples ty simple and added some docs

21e2e01

remybar reviewed Oct 12, 2024

View reviewed changes

bengineer42 added 2 commits October 14, 2024 15:17

addressing comments

684de69

addressing comments

86deb57

bengineer42 commented Oct 15, 2024

View reviewed changes

bengineer42 and others added 8 commits October 16, 2024 14:57

Merge branch 'main' into make-key-tuple/2

3fc7d92

Made the model contract a component

74a4a39

Made the model contract a component

e58d828

test fixed

e8ba30a

Added struct to model tests to test infernce

910c158

fmting

a82ba69

fix: homogeneize the patches

c928ff5

docs: update comments

94cf66c

glihm approved these changes Oct 17, 2024

View reviewed changes

glihm merged commit 7215d47 into dojoengine:main Oct 17, 2024
5 checks passed

		use super::DOJO_MODEL_ATTR;

		const MODEL_CODE_STRING: &str = include_str!("./templates/model_store.generate.cairo");

	const MODEL_CODE_STRING: &str = include_str!("./templates/model_store.generate.cairo");
	const MODEL_CODE_PATCH: &str = include_str!("./templates/model_store.generate.cairo");

	let model_name_snake = model_type.to_case(Case::Snake);
	let model_type_snake = model_type.to_case(Case::Snake);

fix: make the model key a tuple and simplified models code #28

fix: make the model key a tuple and simplified models code #28

Conversation

bengineer42 commented Oct 11, 2024

glihm left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

remybar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bengineer42 Oct 14, 2024 • edited Loading

Choose a reason for hiding this comment

remybar commented Oct 13, 2024

remybar commented Oct 14, 2024

bengineer42 commented Oct 14, 2024 • edited Loading

bengineer42 commented Oct 14, 2024

remybar commented Oct 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

remybar commented Oct 16, 2024

bengineer42 commented Oct 16, 2024

glihm left a comment

Choose a reason for hiding this comment

bengineer42 Oct 14, 2024 •

edited

Loading

bengineer42 commented Oct 14, 2024 •

edited

Loading