|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 05:01:26
Posts: 129,
Visits: 4 817
|
|
| I had something come up where I wanted to database to do the work for me and so I rattled off a OclPS that did the trick, lickity-split! Then I started thinking.... I suppose I should go add an index to the database on the columns I am cranking against to speed things up. Well, that got me thinking.... shouldn't there be a way to specify that an Attribute is an Indexed Attribute? It could have 2 effects, add the necessary index to the database table and Eco could also make some type of memory hash too. In my current case, I really want the index based on 2 Attributes but I figure that might be a lot more difficult to do.
Rick Weyrauch
|
|
|
|
|
Supreme Being
Group: Administrators
Last Login: 2010-07-21 00:21:24
Posts: 1 228,
Visits: 1 373
|
|
In Bold, there was (is) a feature called qualified relations that allowed you to query a multilink like this:
Model snippet:
-------- -------------------------
| Bank | (1) ---------- (*) [AccountNumber] | Account |
-------- | --------------------- |
| AccountNumber: string |
-------------------------
Ocl:
aBank.Accounts['123123']
this would return the account with accountnumber.
This was maintained only in memory with a hash-index that was automatically updated using subscriptions when the account number of an object was changed. There is no such feature in ECO... I've been wanting to add support for adding automatic database indices based on properties in the model for a long time, but never come around to it.
/Jonas Hogstrom [CapableObjects]
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 05:01:26
Posts: 129,
Visits: 4 817
|
|
Well, get on with it! I want it both ways 
Rick Weyrauch
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: 2010-06-30 19:29:39
Posts: 104,
Visits: 314
|
|
I want them 
|
|
|
|
|
Forum Guru
Group: Forum Members
Last Login: 2010-07-08 13:52:20
Posts: 74,
Visits: 531
|
|
there is interface for such type of association, and there feature request already 2 years old for it.
Alex
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 11:08:06
Posts: 256,
Visits: 2 317
|
|
RickWeyrauch (2010-03-03)
I had something come up where I wanted to database to do the work for me and so I rattled off a OclPS that did the trick, lickity-split! Then I started thinking.... I suppose I should go add an index to the database on the columns I am cranking against to speed things up. Well, that got me thinking.... shouldn't there be a way to specify that an Attribute is an Indexed Attribute? It could have 2 effects, add the necessary index to the database table and Eco could also make some type of memory hash too.
In my current case, I really want the index based on 2 Attributes but I figure that might be a lot more difficult to do.
I think that a hook into the DB generation/evolve would be useful, that way I could check for tagged values like "Pete.CreateIndex" and create an index, or add prohibit-delete referential integrity when Eco.IsConstrained=True.
====
Pete
|
|
|
|
|
Supreme Being
Group: Forum Members
Last Login: Today @ 05:01:26
Posts: 129,
Visits: 4 817
|
|
| I was actually thinking the exact same thing. A place where I can define a bunch of SQL that runs after the Eco Create Database. That would have helped me in another project that had some blob fields for storing large binary files. I wanted to place those fields in a seperate FILEGROUP. Eco does not provide a way to set this, but the ability to run a script after Create would have done the trick. Which is exactly what I did - I just had to do it manually via a query window. I still want to ability to tell Eco to make a hash lookup for a given field in memory if I know my users will be thrashing on that field via searches.
Rick Weyrauch
|
|
|
|
|
Forum Member
Group: Forum Members
Last Login: 2010-06-22 11:37:01
Posts: 32,
Visits: 193
|
|
Yes ,I want to them;
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 2010-03-15 08:39:42
Posts: 19,
Visits: 63
|
|
That would be great.
/KrisD
|
|
|
|
|
Junior Member
Group: Forum Members
Last Login: 2010-06-26 12:18:19
Posts: 18,
Visits: 199
|
|
I'd vote for it too.
My model has many associations like this:
Class1 -- (1) ---------------- (*) -- Class2
With Class2 having month : DateTime attribute. And I often search linearly among associated Class2 instances for a one with particular month. So it would be nice to have a qualified association with O(1) navigation time.
Class1 -- (1) ---------------- [month : DateTime] (1) -- Class2
--
Oleg Zhukov
|
|
|
|